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]](http://img.zemanta.com/reblog_e.png?x-id=ac85ab0e-dd1c-4623-bb1a-310acd93b65b)




Comments
This is awesome.
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.)
Content Taxonomy
Thanks for bringing up content taxonomy. It seems like a really good intermediate option.