Posted by john.arroyo on August 18, 2009 at 2:20am
I'm curious if anyone has ever ran into a site or project where they went taxonomy crazy where there were TOO many taxonomies on a node?
3-4 Categories can be common and useful, but at what point do the taxonomies become a burden to performance? 10? 50?
Gut feeling says 5 or less would be optimal, but is it ok to have 10 or 20? I'm curious to get people's thoughts. If anyone has used a ton of taxonomies in a project I'm curious if it worked out for their site. Any links to articles/posts about the topic would be helpful too.
thanks!
Comments
with 5-10 you see absolutely
with 5-10 you see absolutely no difference. With proper performance tuning on both drupal and server end you can achieve very good performance with very large number of taxonomy.
For your question please define " a ton or taxonomies".
------------------
Sometimes interesting things appears on http://litwol.com
Thanks, I just wanted a
Thanks, I just wanted a sanity check about having 5-10 taxonomies per node.
However for curiosity (and potential future dev) I was wondering if there was a best practices upper bound or if someone had experience with a project that had 20-50 taxonomies per node.
John Arroyo | www.arroyolabs.com | www.johnarroyo.com
Too Many Taxonomies vs. Not Enough Node Types
My question would have to be, why WOULD you need that many taxonomies? Performance aside, which as litwol said, isn't a major issue on a properly tuned server, I'm more concerned with the business rules that would dictated 50 taxonomy vocabularies. Is it possible that you just don't have enough content types on your site where you could break things down a bit more logically in that way? Theming CCK types is relatively easy, and assuming that you're already using the same template, or are at least planning to do so, you can probably get away with copying a few files in your theme layer to save you a lot of headache down the road. Leveraging logical breaks, such as content types, as opposed to relying on taxonomy for everything is a more elegant solution.
Mike
Structure taxonomy hierarchically
Or maybe you can get by just using one vocabulary and structuring it hierarchically and have users select terms with something like hierarchical select?
-Daniel
ataxi
What Does HS Do, Exactly?
I read the project page earlier, as I'm new to Drupal, but the description didn't make it clear to me what a real world use case for Hierarchical Select might be. Can anyone clarify?
The best thing to do is to
The best thing to do is to try it! Hierarchical Select is designed to improve the user's experience of using the form items in the "Vocabularies" field. In my experience, though, the menu items take a long time to load in the browser when there are lots and lots of terms.
One of the nice things that Hierarchical Select can do is assign each term in the term hierarchy to the node. For example, if there's a category called "900S" in a hierarchy like "Cars -> Saab -> 900S" then Hierarchical Select can optionally assign all three terms to the node.
6405 and more term, are TOO many taxonomies for me
Hi Guys, in my test site, i have more of 6405 taxonomy term. I'm putting all municipalities in Italy, 8,003 in total with relative url-alias.
My test server is a raspberry pi 3, and when I try to view the list terms of my big vocabulary, my browser does not display anything.
Same speech if I use chosen, in contact form.
I use Drupal 8 and my aim is to create a contact form with a drop down menu where people choose their municipality.
It only works if I use the auto-complete form, but in this case appears also a number next to the term of the taxonomy.
Can you try it in different
Can you try it in different server? I think raspberry is not enough power.
I don't think it is a good choice to ask people narrow down vocabularies to 5~10.
The taxonomy reference fields
The taxonomy reference fields have some explicit warnings about extremely large vocabularies. using this field with really large vocabs will cause out of memory errors (aka white screen of death). just like you are experiencing - this is because the control loads all terms as possible available options. when it does this, it loads the terms into a large entity array, that consumes a lot of memory. It also 'loads' all of the terms which invokes a lot of other processes and can consume a lot of cpu time.
In general, the autocomplete is probably the way to go in this case simply due to the size of the vocabulary, and has the added benefit of not breaking the page. I can't imagine users being fine with searching through 8,000 items in a select box or 8,000 checkboxes/radio buttons. So this is probably the server telling you something now that your users will likely tell you later.
You might also want to consider using something like the "entity reference prepopulate" module, and having a paginated view of municipalities for admins to page through first. Otherwise you are left with what everyone else does - build a better hierarchy and using the hierarchical select module.
re: using the raspberry pi as a server. I'll take the contrarian opinion and say keep using it and just fix the code problem - throwing more hardware at a problem is rarely the best solution to a development problem like this.