When to use different vocabularies vs. one big hierarchical vocabulary with parent terms

Question

Context: I'm developing a website (a directory of things) with a content type "product" that relies on an extensive list with actually two levels: say "productname" and "productvariation". In real life this could be "fruits" or "beer" for the first level "productname" and then "strawberrys", "apples", "peaches" or "stout", "wheat" or "lager" for the second level "productvariation". There won't be a third level as all variations will go on that second level even if they are a subcategory of one variation. It's important that the content type can hold unlimited values of "productnames" (first level) and subsequently unlimited values of "variations" from the selected "productnames".

I want easy editing for the people who will maintain this site. I'm thinking conditional field architecture: User selects one ore more products (radiobuttons or checkboxes)and then the appropriate (select) lists of variations appear for further selecting.

Right now I'm thinking the first level as different vocabs but I don't know if this is the right way?

I haven't found a way to display the vocabs as a list (like a term reference field) so I'm doubting my draft. Is the above a misconception and i should use just one vocabulary?

Thanks in advance!

Answer 1

In the general term you should think on your requisites for these three things, and the pros/cons of the options provided by Drupal core/contrib to accomplish them:

1. How to create and maintain the hierarchy of terms
2. How to pick terms from the hierarchy when creating/editing products
3. How to filter products with a criteria based on this hierarchy (views or programatically filtering)

The way you decide to go for the 1st point (one hierarchical vobcabulary or two related vocabularies) determines the options available to solve the other two points.

When using one hierarchical vocabulary, the most important thing IMO is to preserve the lineage: when classifying a product as strawberry, also classify it as a fruit. This is very helpful to cleanly address the 3rd point without frustration, neither with inelegant approaches. Drupal core doesn't provide a way to preserve the lineage when creating entities. There're several modules out there that ensures it. The most powerful, Hierarchical Select.

Also, editing the hierarchy of terms via the core interface is a bad UX when you go above a few dozens of terms. To improve this there're modules like Taxonomy Manager.

Lastly, eventually you may face scale problems if the vocabulary is huge.

OTOH, using two vocabularies brings other pros/cons.

On the pros side:

• Configuring different fields in each of the vocabularies. For example, in the first level vocabulary (usually called family) a boolean field indicating whether the product is perishable, and a image field in the second level vocabulary for a photo of the variation.
• Preserving the lineage is not an issue, since you are selecting values in two different field/widgets that you enforce to be required.

On the cons:

• You're on your own with two independent vocabularies/fields that needs to be dependant somehow. You may want to create entity reference fields from parent to child, or the other side. You also need a dependant selector widget, eventually you want this widget to work also in views exposed filters,...

The Reference field option limit is great for this setup. It is a bit hard to get how it works, and it has some issues (specially I remember problems with i18n) but it does it pretty nice.

In conclusion:

• None of both approaches works 100% out of the box
• In the one-vocab approach you want to solve the lineage problem
• Two vocabularies is more versatile
• Two vocabularies is harder to setup