RE: RDBMS schema (MySQL)

<[email protected]> Thu, 29 Aug 2002 17:28:25 -0400
Newsgroups gmane.comp.audio.freedb.devel
Message-ID <000001c24fa3$02614d70$6501a8c0@heck>
> Sorry, I don't understand - why would we need that here? We 
> can reference all the information via the id field. All 
> information that can change between variations should not be 
> stored in the disc table (i.e. maingenre, length, discid).

I see, you've taken care of it in your discvariations table.  I justed
wanted to be sure I could lookup all the offset variations given a disc
(master/album/whatever).  For the reasons I mentioned in the 'searching'
E-mails.
 
> Suggestion (based on Ryan's scheme):
> 
> create table disc (
>         id int unique auto_increment not null,
>         revision int not null,
>         program varchar(255) not null,
>         programversion varchar(255),
>         submitteddate date,
>         artist varchar(255) not null,
>         title varchar(255) not null,
>         releaseyear decimal(4),
>         genre varchar(255) not null,
>         numtitles int not null,
>         extendeddata text,
>         fulltext key(artist), fulltext key(title), fulltext 
> (artist,title), key(maingenre), key(releaseyear) );
> 
> create table discvariations (
>         var_id int unique auto_increment not null,
>         disc_id int not null, (--> see id in table disc)
>         subid int not null,

Instead of 'disc_id' could we call it 'ablum_id' or something, or else
it'll get confused with the existing DiscID field.

I take it that subid is DiscID.  I'm missing something: how is the
freedb read implemented?  Doesn't this table (discvariations) need to be
keyed on genre+subid (as well as disc_id)?  And then doesn't var_id
become redundent?  var_id is better then genre+subid because it is
shorter and less cumbersome, but we'll always need genre+subid.

Tom.

>         maingenre char(16) not null, (we can use a number 
> here as well)
>         length int not null, (length can vary between the variations)
>         key(disc_id), key(subid)
> );
> 
> create table discoffsets (
>         var_id int not null, (--> see var_id in table variations)
>         number int not null, (we need the track number the offset
>                               belongs to)
>         offset int not null,
>         key(var_id), key(number)
> );
> 
> create table disctracks (
>         disc_id int not null,
>         number int not null,
>         name varchar(255) not null,
>         artist varchar(255) not null,
>         extendeddata text,
>         key(disc_id), key(name)
> );
> 
> This way we don't even have to define a "master-entry". Disc 
> information and trackoffsets etc. are clearly separated.
> 
> - Joerg
> 
> _______________________________________________
> fdb-dev mailing list
> [email protected]
> http://dtype.org/mailman/listinfo/fdb-dev
>