Re: candidate keys in abstract parent relations

From: Forrest L Norvell <spankysyourpal_at_gmail.com>
Date: 20 Jan 2006 11:47:28 -0800
Message-ID: <1137786448.300512.122610_at_g14g2000cwa.googlegroups.com>


-CELKO- wrote:
> RIAA conventions for naming these things? They have some scheme for
> doing this stuff, so they can sue people easily.

http://www.ifpi.org/isrc/

ISRC identifiers are guaranteed not to change once created, and will probably outlast my database by some time. Unfortunately, they're track-specific (not album specific) and discovering them can be tricky if you don't have the CD handy to do the lookup from the CD's table of contents. It's the track-specificity that's the killer, though. The recording industry generally sees music in terms of tracks, which actually has generalized well to music downloads and the Web, but is strongly at odds with how fans and record collectors think about music.

And, as has been pointed out here and elsewhere, generated identifiers from external sources are just surrogate keys, albeit ones from a trusted source.

At the album level, the only "official" authority I've found is, as I mentioned in my original post, Musicbrainz (http://musicbrainz.org/), which uses GUIDs for both albums and tracks. This creates a dependency in my application that the album exist in Musicbrainz before it exists in my schema, which causes a lot of difficulty in the real world, as Musicbrainz is still very much a work in progress itself.

My schema includes slots for ISRCs for Tracks, ISBN / UPC / EAN codes for Releases, and Musicbrainz GUIDs for Albums and Tracks. Thanks for the idea, though! Received on Fri Jan 20 2006 - 20:47:28 CET

Original text of this message