On Wednesday 16 May 2007, A-NO-NE Music wrote:
I am still far from being comfortable with Drupal. Here is a problem case I need to solve.
I have huge list of musicians who have played for my past gigs and recordings. Many of them has their own website. Some of them will be listed for future shows.
I would like to create 3 sections, Discography, Musicians, and Schedule, where I want to call names from the list of musicians along with its hyperlink for their site.
I've got CCK and View, but I am not certain how I should plan this. Any comment would be appreciated.
You're already on the right track, then. :-) I'm not entirely clear as to your data model, though. Are Discography, Musicians, and Schedule all lists of all musicians on file, just showing different data? Are they searchable/sortable?
I'd defintely start with a Musician node type (or Artist, or whatever). That contains all the data about a single musician. Try to figure out what data on them will be category-like in nature and which is "part of" the musician. For instance, web site and number of people in the band are "part of" the musician entity. For those, use CCK fields. Whether their music type is rock, jazz, or disco would be a category-style bit of data. For that, use a taxonomy vocabulary called "Music style" with possible terms rock, jazz, and disco.
From there, you can create lists of musicians using Views by whatever attributes you want. Eg, all musicians who play jazz, name and web site. All musicians with more than 3 people, grouped by their music type. Etc.
For Discography, there's lots of ways you can do that. You could have an "albums" field on a musician node that just lists album titles. Alternatively, you could have an Album node type that has a nodereference field that points to the musician node responsible for it (as well as year, label, who did backup vocals, etc.). That gives you the ability to create lists (Views) of album nodes, too, with links to their musician, grouped by musician, etc. I'm sure you can think of lots of other cool things to do with that sort of data.
You may or may not want to go this route directly, depending on what it is you're lookig to display, but hopefully the above gives you an idea of how to go about designing your data model "the Drupal Way". I would definitely advise erring on the side of a richer data model that you're not using rathern than a simple one that you may outgrow. You can certainly make headaches for yourself either way, but IME it's better to have too many options than too few.
Cheers.