From: David N. <dav...@gm...> - 2004-11-30 06:27:34
|
> primary key. But you seem to be assuming that _all_ PKs will be > artificial sequence-generated integers, which may or may not be true. for the assigned problem domain, using artist names as PKs would be easier to work with IMO, at least for the artist/band table. Those guys tend to have unique names to avoid confusing with each other. "Cher" and "Cher UK" are two separate artists with two separate names, there's no need to call one of them artistID 2245 and the other artistID 9877. > Even if all non-"linking" (for lack of a better term) tables have such a > PK, in many cases this PK is simply to make some things easier, and the > table should have an additional key defined. For example, looking at the > ERD, we _could_ add a "trackid" PK to the track table, but we'd still want > to have a key of "cdid, songid, tracknumber". > > As a side note, I note that that table's PK is defined incorrectly as > "cdid, songid". There's nothing to prevent a CD from having the same song > as two different tracks. It's odd, to be sure, but hardly impossible, and > I bet there is an example of that out there. they often have additional distinguishing characteristics in the title, like "alley cat mix" or something. But they are the same song. And the same song very often will occur on multiple recordings, especially if you get into bootleg live albums and whatnot. Good songs will get recorded by lots of different artists. I would give the songs table a PK of a combination of the name of the song and the credited author of the song, and a list of different versions; versions refer to artists and get some comment text, and recording,track information. -- David L Nicol |