4

When we want some specification for a content, how should we decide whether to make that specification a separate content type or a taxonomy term?

For example, I had to build a music store site. The main content was music tracks, albums, label, music director, and producer. I made a content type (Music Tracks) and albums, label, music director, and producer were taxonomy terms which were given as entity references in the Music Tracks. Then, I was suggested to make the site scalable and thus making album, producer, and label a separate content type.

So how do content types help in making the website scalable?

1

There are also other solutions to your problem.

Field Collection

You can use field collection and field collection views modules to store and organize contents. Using this approach the Issue and Magazine are going to be Field Collection type, Issue is a field of Article and Magazine is a field of Issue. I have experience of implementing such structure. In my case the requirement was a Library that should contain books (with Title, Publisher and ... fields), Every book contains multiple volumes (Number of pages, translator, ... ) and each volume also contains unlimited number of some other items (like the scan of some pages that are not the same among the books).

I implemented this using Field Collection approach and it is very nice. You can easily create a link to edit every individual items of every field collection and you can also filter by items of field collection. I posted an answer to Group items in Views by value in Field Collection which shows how to work with Field Collection Views

Entity View Attachment

Also known as EVA module.

"Eva" is short for "Entity Views Attachment;" it provides a Views display plugin that allows the output of a View to be attached to the content of any Drupal entity. The body of a node or comment, the profile of a user account, or the listing page for a Taxonomy term are all examples of entity content.

You can use EVA to display only fields values for a particular piece of content, giving incredible control over the display and formatting flexibility of the fields. For example you may desire to have two fields concatenated in some special way. You can add your fields to your EVA display, set the contextual filter to NID, add a Global: Text Field, and using tokens format your fields with HTML. Don’t forget to exclude your fields from display if you are going to use them together in a Global: Text Field. Example: You may have a city, state, and zip fields. You can combine them in a Global: Text Field in Views to display as “City, State ZIP”. When you manage the display for your content type add the EVA just created to the display and whenever a node the type is displayed it will pass its nid to the EVA and the EVA will return the fields you select, formatted as you desire. (source : EVA and Entity Reference Use Case How-to)

This module is perfect, It attaches a View as a field to nodes of a content type. I used this module to create an Album. The album contains singer (with some information about each one) and songs that contains a File, Title, Rate and ... . So I created a View of type EVA and I attached it to a node. So on the node page of every Singer, I displayed this View which gets it's appropriate information from the node. The Views with Entity Reference is a perfect tutorial of how to use this module.

Taxonomy Terms V.S Entity Reference

I recommend you to read Entity reference vs. taxonomy and Are there any benefits/caveats with using Entity Reference over Term Reference? , As it says Taxonomies are best used when organizing similar items in a hierarchical fashion. Like tags.

Taxonomy allows you to use free tagging (it can be disabled using Content Taxonomy module), which enables the creation of new tags on-the-fly. It is very easy to modify the skeleton of contents. Using this approach, regular or at least some authenticated users (who have no knowledge of programming) can change this skeleton. Hierarchical Select module is perfect example of such approach.

Even though Taxonomy is easy to use but I myself prefer Entity Reference, it opens up lot's of possibilities and scalability and allows of creation very complex structures. The concept of entity in this context is not limited to content. It can be comments, users, taxonomies and ... . It is much more scalable so you will not be worry about the customizing content types, or modifying it in the future (as it was pointed out in Entity reference vs. taxonomy). I believe the Entity approach is more powerful than Taxonomy.

There are also some other combinations of these approaches which it is unnecessary to mention them.

Anyway I recommend you fully understand Entity approach and it's related modules. If you use it in multiple projects, despite of it's complexity it will be very easy to you to use it. Not only in the yours current requirement but also in the future it is going to be a Very Reliable Tool for you.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.