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 >