RE: RDBMS schema (MySQL)

<[email protected]> Thu, 29 Aug 2002 15:59:15 -0400
Newsgroups gmane.comp.audio.freedb.devel
Message-ID <000101c24f96$8d5b3a10$6501a8c0@heck>
> On Thu, 2002-08-29 at 14:51, Joerg Hevers wrote:
> > >         id int unique auto_increment not null primary key,
> > >         length int not null,
> > >         discid char(8) not null,
> > 
> > Why would you need the discid here at all?
> 
> I'm certainly not understanding something.  Doesn't anyone 
> ever search on discid?

When someone searches on discid (+ offsets) it finds the entry in the
offsets table and then links to the album.

But I think we need this field (discid) here and that it should be an
array of genre+discid - ie. links into the offsets table.  Or, if you
implement the new albumid-discid table that one of you mentioned, it
would need to go both ways.  Can the DB do that?

> I think my schema is ok in this aspect.  The main reason 
> being that all the tables are linked to the main album via 
> the id index in the disc table, not the discid.  This would 
> allow multiple albums to have the same discid, and still be 
> uniquely identified by the id index.

That sounds like a good design, but would it work in practise?  I guess
a CD-ripper program could work as follows: user inserts CD, a matching
entry is found and presented to user, user rejects this result and
submits a new album.  I guess that would work.  Good idea.

Tom.
 
> Thanks for your feedback.  I'm certain I have a lot better 
> feel for the data structure now then when I started.
> 
> Thanks,
> Ryan
> 
> 
> _______________________________________________
> fdb-dev mailing list
> [email protected]
> http://dtype.org/mailman/listinfo/fdb-dev
>