[PATCH] ReplayGain tags

[Gregory Meyer]

On Sun, Jan 11, 2009 at 6:27 AM, Seb Ruiz <ruiz at kde.org> wrote:
> 2009/1/11 Edward Hades <edward.hades at gmail.com>:
>> The first is that, perhaps, from the general view of database design, it would
>> be better to put replayGain stuff in another table, referenced by foreign key.
>
> Not quite. If a track has either 0 or 1 value for artist/track gain,
> then the design is already normalised and doesn't need another table.
>
Although as you all know I am not a programmer, I do have some
database experience due to my interest in accounting information
systems, so I think I can comment here.  I don't think that a separate
table is necessary as for these values, as the track gain value in
particular are unique to a track, so if you have 5,000 tracks, you
will have 5,000 records in the replaygain table.  So since the point
of normalization is to reduce the size of the database, you have
actually done the opposite by introducing another key field.

The album gain information is not unique per track but unique per
album, so from the standpoint of making sure the database is properly
normalized, perhaps this should be stored in the album table,
although, since you are already updating the track record with the
track gain, it doesn't hurt too much these days to have some redundant
data in the track table.  I'd also say that it probably makes more
sense to leave it in the track table just because it makes the schema
easier to understand.
--
Greg