Amarok Datenbank-Backend

[Maximilian Kossick]

On Sunday 09 September 2007, Tobias G. Pfeiffer wrote:
> Hi!
>
> Am Samstag, 8. September 2007, 09:12 schrieb Maximilian Kossick:
> > In my planned DB schema, the tags table was basically renamed to tracks.
> > The other two major changes are the introduction of the url table
> > (although i'm not quite convinced that we actually need it, I need to
> > think about this some more) and a modification of the columns of the
> > album table.
>
> As I understood it, there is a 1:1 mapping between a track and a url, so I
> don't think an additional table makes sense here. I noticed that you do not
> ever have primary key constraints for the id columns of tables. At least in
> Postgresql, "primary key" == "unique && not null", i.e. the column is
> always indexed, which provides lookup in logarithmic time. Since accessing
> rows by id (numerical comparison) is much faster than by url or any other
> string (especially when about the first half of this string is the same for
> all tracks, as to be expected in file urls), I recommend setting a primary
> key constraint for all 'id' columns and then try to access table rows by id
> as often as possible.
> Since Maximilan said he does not have too much time for Amarok these days,
> I'll try to make the changes I think are necessary in the code, if no one
> objects.

you should check what the implementations of SqlStroage::idType() return:)
About the url table: we have some very complex logic to try and make sure that 
we don't lose statistics for songs, even if the file is deleted and later 
moved back again. Therefore i think we should keep the url table, otherwise 
we have to keep the url in the statistics table too, which is going to make 
maintenance a lot more complex when we do stuff like moving a file inside 
amarok.

> > Unfortunately, the code in DatabaseUpdater.cpp is the only place I ever
> > stored the database schema. eean asked me to create a diagram once
>
> -> docs/database/amarokTables.svg
>
> Bye
> Tobias


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20070909/0d2e45e1/attachment.pgp