When importing to CCK content types, a very good understanding is needed of the clients old database, what their business use cases are, how they interact with the data, and what are the new requirements.

The content types have to be created and have approval from the client that, they work in the way the client is expecting, before the bulk of database migration is started.

Creating content types

The customer may identify different grouping of pages that they are likely to create, e.g. news releases, products, companies. Depending on how each grouping of data interacts with each other, it could be either:

content type

• content types can be as simple as all the data in the body field, or depending on how the client may want to sort and filter data, each piece of information segregated into fields
• make use of node reference fields to describe relationship between content types, e.g. a film has many actors, where both film and actor are both content types, since the client describes details about both films and actors
• if the client does not store, and will likely not store more details about a piece of data, e.g. festival, then festival would be a taxonomy instead.

vocabulary/taxonomy/category

• used for a simple list of items. Very powerful tool. Not used when there are more details describing that vocabulary term. For example: book awards could be a vocabulary for one site, for another site, that is mainly concerned with awards, it would be a content type. As a content type, more details about each book award can be stored, sorted, filtered and searched.
• if in the first phase a type of content is stored as taxonomy, and then later the customer decides to expand the use of that content, no need to stress, it is not too difficult to convert taxonomy terms into nodes.

custom field

• node/view reference field

drop down CCK fields

• be very wary and hesitant of using drop down CCK fields
• mainly useful for static grouping of items, e.g. yes/no or Monday/Tuesday ... /Sunday
• use taxonomy or node/view reference instead if listing is likely to be altered.

If approaching content type bloat

• consider to combine content types together; for example instead of having ppl_actor, ppl_director content types, an alternative is to have people content type with a vocabulary of person type (actor, director, etc.).
• The benefit is that there would not be 2 or more nodes describing a single person.
• With 2 or more nodes of the same entity, it becomes difficult to accurately show all movies Paris Hilton acted in as well as all songs Paris Hilton sung in with a simple view.

The proper data architecture, as in proper for that client, not proper for all clients, will determine how easy or difficult it is to accommodate likely future feature requests. This will impact the maintainability of the website as well.