IA and when to use nodes or taxonomy terms
renee - July 8, 2009 - 18:38
I have a weird problem. I have a huge list of things (occupations), over 600 of them. Each one of them has a name, a code number associated with it, a description, and a location in our library.
I had originally set it up using terms and descriptions, before the code number and library locations were needed. So what do I do? Should I convert each term into a node with its own CCK fields for the code number and location? That seems like an awful lot of nodes for only a few bytes worth of information. But I can't think of any other way to do it.
Anybody have any better ideas? :)
+1 for nodes.
+1 for nodes.
I see two main approaches
Were you tagging other nodes with these occupation terms? I'll assume yes - otherwise there wasn't much point using terms :)
The two approaches would be:
a) Using nodes: You could make them nodes, but then you'll need to figure out the node relationship stuff to connect them back to the original nodes.
b) Storing the data yourself: You could create a module to store the extra data in the database somewhere - eg in it's own table linked by term id, or as extra fields on the terms. The extra table might be better than using extra fields on an existing table.
It all depends on how you want to get at and display this extra data.
--
Anton
tagging
Thanks for the suggestions! Yes, I was tagging other nodes with the occupation terms, we have company profiles and degrees, both of which use the "occupation" vocab. I suppose I could just create a node that has a 1:1 with each taxonomy term and contains the extra values, that may might be easiest...
Nodes
What are occupations right now? "Terms and descriptions" usually refer to taxonomy, which is not about data storage, but about relations between (already-stored) data.
Since each occupation has unique fields associated with it, then you really should have made each occupation a distinct node in the first place. I'm honestly at a loss as to how you have the data stored now. If they are individual nodes, then creating more fields (e.g. code numbers and locations) is trivial, both in terms of programming and data storage.
-Karlheinz
Taxonomy is the way to go
You can add additional fields to taxonomy terms, this is quite trivial either code it yourself or use one of the modules available, this is likely to be in D7 core as well, bringing fields to taxonomy is high priority, partly for the exact reason you need them. We even did a site early in D6 cycle that had fivestar data stored in taxonomy terms, users could rate terms.
Creating nodes would be a pita, its far less trivial to create the one to many relationship needed than using taxonomy, which has all the power of the taxonomy system and Views integration going for it.
Stick with taxonomy, and look deeply into the whole "fields for taxonomy terms" development going on here in d.o.
Professional Drupal Design and Theme Services