Hi TriDUG- good to meet you at my first meeting on Wednesday!
I have some really elementary questions. I'm used to a relational database background- with parent and child tables related with ID fields, and I'm having problems correlating this to the Drupal environment.
For instance- we will have pages for each Species, and pages for each Animal. Species data would have fields like average weight, habitat, range, prey, etc. Animals would have data such as Animal name, birthdate, how they came to Carolina Tiger, personality, and of course a Species ID field.
So the Species web pages would display the Species fields in a consistent manner, and there would probably a block listing the animals of that species, all our tigers, etc., with a link to their animal page.
But I'm confused- should species and animals then be Content Types, Taxonomy vocabulary terms, both?
and to add to that confusion- I need all the species types and animal names for use as tags- so that on the Tiger page, the slideshow shows tiger images, and so forth
How does my regular terminology: tables, fields, records- relate to Drupal terminology? What is an entity?
just need this little bits of direction to really get me going, and I promise my questions will get more challenging quickly! :)
thanks, Amanda
Comments
Great question, good to see you here
Amanda,
Welcome to the fray. Great question, too. Some things to consider
Content types relates to the organization of interrelated data that will display on the same page. We can tweak which fields in our content type displays, depending on a number of factors, btw. So think of Content Type as the superset of data that you would possibly want to show for an animal.
Taxonomy is more purely used a data paradigm.
SO
"Animals" will be a content type but species (a classic use case for demonstrating taxonomic hierarchies, btw) would be how you assign an attribution to an animal. "Species" will be a term reference field you use with "Animal" i.e.,
tiger >bengal
indochinese
malayan
sumatran
etc
https://drupal.org/project/taxonomy_menu is a popular module that may help with navigating your "animal" database.
I hope that helps.
further confusion
well, we'd have a species web page for each species represented, and an animal page for each animal- so having them be different (one content type and the other vocab) strikes me as odd. It's like taking two pieces of fruit that look the same to me, and calling one an apple and one an orange.
I wanted to go even further and have an animal journal for each animal- which would be another step down in the hierarchy- and might be used by volunteers to record animal care events- date, type of care, notes... with the ultimate plan of using for reports, etc. in animal management.
So now what? Can content types relate to each other, or should content types always be bottom level in your data hierarchy? And aren't both my website's "animal pages" and "species pages" just "basic pages"? How do I get a list of our tigers on the tiger species page- by creating a view with a block that lists animals filtered by species type?
Separating data from display
One is essentially a specific type of field (taxonomy) and the other is an organization of fields (content type)
am I getting it?
So here's what I'm kind of thinking:
Content Type: similar to table
Taxonomy: creates values of picklist fields, sometimes layered
am I on the right track?
Content Types
?
Taxonomy Vocab
nice!
I believe getting used to the "drupal" way is time best spent at the beginning, rather than cobbling a site together to only then realize you need to start over anyhow.
Yes you're on the right track:
Content type:
How dramatically different is the "species" and "animal" displays, field-wise? Is "animal" a subset of "species"?
Taxonomy:
Looks good to me. I presume these are flat, non-hierarchical lists?
Also: I read your notation as suggesting multiple fields associated with, for example, "Species Name" "field name: tiger" "field name: lion" where it would be "field name: species name" with row values "tiger" "lion"
I hope you don't mind my being pedantic.
Or use Entity Reference
You could use the entity_reference module to reference one node to another.
Or you could create a taxonomy for structure, then create a node for each "page", then use a taxonomy redirect to bounce them from the taxonomy term page to the node page. You can then use community tags to tag each page, then use Views to create blocks that list all nodes with that tag/term. But you could also just have fields and use Views to create listings of values entered in those fields. If you need a hierarchical structure you'd probably want to go with taxonomy over fields. If you're not showing the whole hierarchy then keeping all the data in a node might be easier to manage and just use views to pull a list of all "Tigers" that are noted as such in a species name field.
Ultimately it all depends on whether menu structure is sufficient for creating structure or if you need listing pages. Also depends on how much info and "page" specific content you'll need for each subject matter as that would likely be better as a node type than a taxonomy term page.
Since you can use display suite to create the layout for taxonomy terms or content types, that doesn't vary much except for getting into complexity with creating views for taxonomy term pages that pull data based on that term, a little more effort than a view on a node page that lists "Tigers" from a tag/term.
Ultimately, be prepared to start over and do it a different way as hinted at above, so I wouldn't get all into filling-in all your data as you go until you've created a few test scenarios/nodes/vocabularies/terms/views to make sure it works for you as you need it to.
DEAN FLORY
Cary, North Carolina, USA
Learning something every day...
Age old question
Lots of good advice already given on this question, but this is a great question, and one I've personally struggled with myself. To me it boils down to: use the Entity Reference field or use a Taxonomy term? For me the decision point comes down to whether or not there is related information to go along with the entity. If the related entity is really just a term, then use taxonomy. If the related entity has associated data like location, size, count, etc., then make it a content type that is related by an Entity Reference field.
Here's some other free advice that may or may not be worth the price:
Good luck!
Thanks All!
This will be incredibly helpful moving forward with planning the underlying content infrastructure- looks like there's different ways of organizing and which way is best depends on what you want your site to do. It's also helpful in helping me wrap my head about a new way of thinking about data, and pointing out the subjects that require more contemplation. :)
I think my best bet is to continue laying out my ideas for my "wireframes" (maybe you would call 'views'- just which blocks I want on which pages). That should help lay out HOW I need to be able to organize.