> Here are the features it seems we're interested in having in the DB.
>
> First, basic features (largely CDDB compatibility issues):
>
> * DiscID - Xmcd hash, for compat.
> * Artist - primary artist on the CD
> * Title - primary title for the CD
> * Disc Info - extra information about the CD
> * Playorder - suggested playing order (is this stored in the network DB,
> or just local?)
>
> and for each track:
>
> * Track title -- title of the track
> * Track ext info -- extra info about that track
>
>
> I think we all agree that we need at least these features, at a bare
> minimum.
I suggest removing "Playorder".
I also think "Artist" belongs to the "for each track list".
A general solution to the sub-title, sub-artist and sub-everything
problem is to allow multible instances of every (or at least some of the
identifiers). Every track can have multiple titles, and multiple
artists.
> Plus, we probably would want to support:
> * International characters
> * multiple language records
> * Multiple disc ID systems (might be best to just record the M:S:F
> information for all tracks, and let people ask based on that information.
> to hell with hashes! :-) )
> * abbreviations for Artist, Track, etc. (to allow display on small
> screens, like car displays or consumer Jukeboxes)
Yes yes yes!
> What have I missed?
I believe most people on the list agrees on many of theese points - so
let's focus on the points where there is disagreement:
1. issue: What "Tables" should be used?
I suggested CD, song and artist.
Some suggested just CDs for simplicity
Others suggesting bringing in a new table for media-type
I think it's a good idea to divide the data as much as possible (to a
degree). It will make the database more flexibel in the future. I
honestly don't think performance will be the main issue here!
2. issue: How should data be tagged within the table?
(I don't mean as in if we use XML or a new protocol)
I suggested using an identifier (like "Title", "Artist", "Name") and an
data-type (like "id", "string", "url" or "email"). Others have suggested
using just the identifier.
My reason for adding the data-type was that it will be easier to make
stupid clients parse the data correctly. The client doesn't have to know
the difference between "Lyrics" and "Publisher", but only the difference
between "string" and "url". This will make it a lot easier to add new
fields (sorry if i'm repeating myself)
3. issue: Place the fields into the correct tables.
I believe you're mail is an excelent start, but depending on the choices
made in issue 1, one might want to do minor changes.
When theese 3 issues are settled, I believe it's time to concentrate on
protocols, replication and simular problems.
Ragnar Kjørstad