How to Decide Between Using Taxonomy Terms and a CCK Field to Classify Content on a Drupal Site

I often have a hard time deciding whether to use a CCK field or the taxonomy module when building Drupal sites. At Drupalcon, I was glad to see that I am not alone in my confusion. At the Drupalcon Drupal Taxonomy Revisted session, I finally started to understand the use case for each.

Here’s a table I put together to help me quickly decide whether to use taxonomy or CCK in the future.

Question Which to Use? Rationale
Do you have a lot of terms or attributes? As the size of your vocabulary or field option list grows, taxonomy becomes a better choice CCK stores its values as text while taxonomy stores values with an ID. This makes lookups over a large data set more efficient for taxonomy.
Are you using a hierarchy? Taxonomy Taxonomy is designed to handle multiple levels of hierarchy, which a CCK field is not
Are you listing attributes? For example, listing the color options of a car. CCK CCK makes more sense if you have created a content type and are adding attributes to it using CCK fields. For example, I could have a car node type and color would be a CCK field
Does your piece of content exist in the real world on its own? Taxonomy Taxonomy terms are designed to map to real-world objects in a way that CCK fields are not. For example, if I have a taxonomy of US States, each state exists whether or not I have assigned content to it.
Will you re-use your term or attribute in multiple ways within your site or re-organize them? Taxonomy If you have a classification such as US States that you plan to use in multiple node types, then taxonomy makes more sense. It is easier to add new terms to taxonomies over time than to individual CCK fields.
Are you using CCK or taxonomy to list critical information on your site? What is the cost of losing the data if you upgrade to a future major Drupal version? Taxonomy Taxonomy is more futureproof because each term has its own unique id, and, it can be moved between vocabularies. Taxonomy is also a Drupal core module and there will almost certainly be an easy upgrade path from Drupal 6 taxonomy to Drupal 7 taxonomy.

An Example: Classifying Topic Areas

Using this criteria, making the decisions I was stuck on in an earlier blog post becomes a lot easier.

Question Response Decision
Do you have a lot of terms or attributes? Yes, we have at least 200 terms and that number is likely to grow dramatically over the next few years. Taxonomy
Are you using a hierarchy? Yes, we have at least 3 levels of hierarchy. Taxonomy
Are you listing attributes? For example, listing the color options of a car. No, we are listing topics that span multiple content types. Taxonomy
Does your piece of content exist in the real world on its own? Somewhat. Greenhouse Gas Inventories exist in the real-world, as does the “Climate.” The category “Campus Operations” is more of a grey area Probably Taxonomy
Will you re-use your term or attribute in multiple ways within your site or re-organize them? Yes, we plan to classify many different node types with the same terms Taxonomy
Are you using CCK or taxonomy to list critical information on your site? What is the cost of losing the data if you upgrade to a future major Drupal version? It would be painful to lose all of our classification information but I don’t think that it would destroy us as an organization. CCK or Taxonomy

After evaluating which to use with my new handy chart, it’s clear the taxonomy makes more sense for classifying our topical areas.

Reblog this post [with Zemanta]

Comments

I feel like I've had this question pop-up several times in the last month on two projects. I actually made a gray area choice.

One rational I didn't see in your post is whether or not site editors will need to be able to occasionally add to the selection list. I really hate to allow access to 'admin content types' to anyone but a few core developers.
I've chosen to set up the list as a vocabulary (for easier adding) and use the Content Taxonomy module, to apply it to nodes as a CCK field.

NOTES: You can select whether the value will ALSO be stored in the in the core taxonomy system (in the term_node table.) You can also whether this CCK add-on should remove taxonomy relations from the node type (so as to be linked via the module.)

Thanks for bringing up content taxonomy. It seems like a really good intermediate option.