RE: RDBMS schema (MySQL)

<[email protected]> Thu, 29 Aug 2002 15:36:44 -0400
Newsgroups gmane.comp.audio.freedb.devel
Message-ID <000001c24f93$686065d0$6501a8c0@heck>
< create table disc (
<         id int unique auto_increment not null,
< 	length int not null, 
< 	discid char(8) not null unique primary key,

How big is a MySQL int?  Is it signed or unsigned?  32bits would be
sufficient for the album id ('id' in your table).

DiscId shouldn't be char(8), it should be a 32bit unsigned integer.

> data normalization, I think artist name and genre should have 
> separate tables.  This would make it easier to search for 
> albums by the same artist or genre, as well as use less disk 
> space.  I did not implement the disc table in this fashion 
> because of the difficulty in converting from the current 
> format to that normalized format.  It would probably be 
> easier if we moved from the current format to this 
> intermediate sql format, and then moved towards data 
> normalization in a later version.

Having a seperate table for artist would be good, but there are
complications.

For genre though, why don't we simply use a 4 bit code (I think ID3v1
defines enumeration values for these genres).  Then, (genre + discID)
could be used as a unique key.  You will need to use this key in the
offsets table as well.

This key would be 36 bits, so you might as well make it 64 bits.  I know
that windows (C/C++) has a 64bit unsigned integer type, do Linux, Java,
dotNet?
 
> Perhaps we should also store when an entry was submitted (important
for generating update-> > archives (we should still think about
releasing the database archives).

Good idea.

Tom.