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.