Pupeno <[EMAIL PROTECTED]> wrote on 01/26/2005 11:53:06 AM: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Je Merkredo Januaro 26 2005 18:56, [EMAIL PROTECTED] skribis: > > For instance, when Eric Clapton did his unplugged version of "Layla", he > > was the same ARTIST as recorded the original studio version but he was > > part of two different groups. The first time he was part of the group > > "Derrick and the Dominoes" and the second time he was part of the group > > "Eric Clapton" (GROUP does not equal ARTIST) > If for example, someone played the drums for Eric Clapton on that > performance, > would he have 'joined' the 'Eric Clapton' group during that performance ? Or > for example, when Paul McCartney goes doing a tour as Paul McCartney, do the > musicians who go with them join the group Paul McCartney ? > Thanks.
I guess that all depends on the level of detail you want to keep. "Legal" membership (with contracts and all that) is one condition but acting as a studio or backup player is another. If you want to make that distinction then you would assign backing artists to the Recording and not make them members of the group. The group 'M' is actually only 1 person, Robin Scott. However, on his single 'Pop Muzik' he had two female backup singers. Legally, they weren't part of the group (because he was the only official member) but they do appear on the recording. What you need to decide, now and not later, is if you are even interested in this level of detail. If you are, I would associate those ladies with the Recording not the Group. Otherwise, just leave that information out of your database. > - -- > Pupeno: [EMAIL PROTECTED] - http://www.pupeno.com > Reading Science Fiction ? http://sfreaders.com.ar > > PS: I'm not sure how to handle the interface for this, I mean, people won't > really understand that Eric Clapton IS a group if I list him under "Groups". > Any recommendations ? I think they will so long as they understand that in the context of their search that the name "Groups" means "who recorded the music". Off the top of my head Eric has recorded as himself, as a member of the group Cream, as a member of "Derrick and the Dominoes", and as a supporting musician for a lot of other artists. If you are searching by group names, you only turn up "Eric Clapton". If you are searching for recordings that have Eric on them, you will find them all. How you design your search page will make all the difference in what the user "thinks" they are looking for (perceptions are 90% of the battle). How you organize your database will make all the difference in how well your application responds. There is one VERY important thing to remember. What you call the entities in your database can be entirely different than what an end user thinks they are. Whatever label you put on your web site or in your application's GUI *DOES NOT* need to correspond to the actual "name" of the data you are presenting. If your users understand what you mean, you can call it anything you like on the "back end" so long as your "back end" name makes sense to you. In our case, we need to name a table to store data about an entity that creates a recording. A few possible names for that table would be "Group", "Band", "Artist", or "Orchestra". We also need to name a table to contain the names and other biographical information of the actual people that participate in the recording industry. Possible names are "Person", "People", "Artists", "Humans", "Gente", "Hombres", "Mujeres", etc. However there are problems with most of those names. They are just not generic enough to fit our needs. If we create one table for just men and another for just women, then you would need to reference and coordinate between two different sets of IDs when looking up anyone's name (not fun). The name "Artists" appear in both lists of potential names. That means that we need to decide which entity we call "Artist" (if we even use that name) and which one gets an alternate name. How about we not use the table name of "Artist" and instead call it "Person"? That way you can't be confused between the name of the thing (BAND/GROUP/ORCHESTRA) that works together on a recording and the people that make up that thing. It's all a matter of _definition_. We _DEFINE_ that "GROUP" (or whatever) will the name of the table of those things that make recordings and "People" is the name of the table of those things that make up a "GROUP". People can also be producers, engineers, etc. so that name fits rather well, I think. The basic rules of normalization says that you should only store 1 copy of any entity in your database. That means that we shouldn't have a list of people that were engineers and a separate list of people that were part of groups and another list of people that did arrangements. We need one list of people and whenever one of those people did something (they were a member of a group, the arranged a song, etc.) we create an entry in another table that shows that relationship. Each of those relationship tables can be called anything you like, so long as that name makes sense to you because usually only you and the program you write will be the only things who actually work directly with the database objects. Shawn Green Database Administrator Unimin Corporation - Spruce Pine
