[support] Newbee: How should I plan this?

[Mike Bishop]

The thing I try to do the most is to separate the content out as much as possible. Keep things as "logical" as you can so that you can be flexible with how to use it. The problem arises when you want to start making relations between all of the different node types.

But you are definitely on the right path.

One thing that Larry mentioned about the discography can get tricky. If you seperate out the Discography into individual nodes, you might run into trouble just showing "Artist 1's" discography in one list. 

http://drupal.org/node/124446

This is a great solution but not very flexible. 



-----Original Message-----
From: support-bounces at drupal.org on behalf of Larry Garfield
Sent: Wed 5/16/2007 10:56 PM
To: support at drupal.org
Subject: Re: [support] Newbee: How should I plan this?
 
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.

-- 
Larry Garfield			AIM: LOLG42
larry at garfieldtech.com		ICQ: 6817012

"If nature has made any one thing less susceptible than all others of 
exclusive property, it is the action of the thinking power called an idea, 
which an individual may exclusively possess as long as he keeps it to 
himself; but the moment it is divulged, it forces itself into the possession 
of every one, and the receiver cannot dispossess himself of it."  -- Thomas 
Jefferson
-- 
[ Drupal support list | http://lists.drupal.org/ ]


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 4794 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/support/attachments/20070517/6c240e49/attachment.bin