13

This may be a silly question, but I'm curious what the benefit is of using a list (text) multiple select field over a taxonomy term reference field. They both seem to fill roughly the same function of giving predetermined multiple choice options, but taxonomy has the added benefit of allowing you to add terms after content has been written to the database.

So is there any good guideline for one to use one or the other? (And particularly when list(text) makes more sense than taxonomy term reference?).

3
  • 2
    I try to think of a taxonomy as 'way to categorize data in a structured manner' (including tree structures) and lists as 'Offering several defined options' when organization isn't important. When in doubt, I pick taxonomy, since the integration into browsing via Views is quick to implement. Feb 27, 2012 at 15:14
  • 1
    The one thing select/text can't do is structure data hierarchy; Taxonomy alone offers trees.
    – Renee
    Apr 10, 2013 at 0:13
  • There's an article about this at eosrei.net/articles/2013/12/….
    – colan
    Oct 10, 2017 at 14:43

4 Answers 4

11

Structure and dynamic are IMO the keywords for choosing taxonomy. I recently had this question come to me when tagging companies with geographical regions. My first choice was to prepare taxonomy with list of regions. Soon it turned out to be over-complication. The regions almost never change their names and almost never change their structure/parents. So I tossed out the taxonomy and decided to use a flat List (Text). It's now also much easier to maneuver the regions in a View. So - if your list is static and flat - go for a list.

2
  • 3
    Well there's one obvious thing which slipped my mind - I'd say use taxonomy when you want the tags to have their own pages, filled with custom fields, images, displayed in various modes (full, teaser, etc.) Apr 30, 2012 at 11:58
  • accepting this because it gave some pros and cons. Patrick Kenny's point about performance is important too though.
    – Jay
    May 21, 2012 at 13:04
8

Taxonomy has performance issues as it scales because the SQL queries get longer; if you are using views filters, select lists will be faster than taxonomy.

1
  • That is generally true, but with experience you get to know that you should use SOLR search for scaling views with filters so it doesnt matter much then.
    – Blissful
    Nov 22, 2018 at 9:01
7

The key differentiations I learned were:

  • do you want users to be adding to the list of values, not just site admins or, will adding to the list be a semi-regular need for even site admins?
  • do you want to use the value as an organizing piece of content itself (as suggested above by @Artur, creating pages of all content that shares this term, with different layouts, like a product page: show all XL clothes; or news, show all Sports)
  • is the data at all hierarchical? (eg: subcategories where you'll want to capture the parent category sometimes or the children separately at others)

If no to all of the above, use select/text. If yes, use taxonomy terms. You'll usually use select/text, in my experience. It always feels wrong, but it's usually right.

0

Clear winner in my opinion would be taxonomy term, more power, little downsides.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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