[prev in list] [next in list] [prev in thread] [next in thread] 

List:       amarok-devel
Subject:    Database
From:       "Alexandre Oliveira" <aleprjlists () gmail ! com>
Date:       2007-02-23 2:20:26
Message-ID: be280ab80702221820s65524564rfede06490481b310 () mail ! gmail ! com
[Download RAW message or body]

I wanted to start some discussion about the database on IRC yesterday,
but as I didn't understand the database very much myself, I wasn't
very successful.

I didn't follow very much the two deep changes on the database we had
recently, and which happened almost together, the Dynamic Collections
and AFT.
Both changed the way our tables link, and they added some (necessary)
complexity.

Anyway, as I was really bored and I wanted to do something, I decided
to build a diagram of the current shape of our database. After trying
some apps like Kivio and Dia I run back to ErWin, which's a commercial
app for windows that I had been obliged to use in the past, and thus I
was quite familiar with.

As we don't define foreign keys (only one for the labels!), the
current picture of the database was actually bizarre, and wouldn't
help at all with the planning. So I just got the tables and added what
I think the proper links should be. Max and Jeff, please check if this
is actually what you planned.
Note that I'm not suggesting this schema, it's just supposed to be
what we have now with 1.4.

The idea is using this current schema to discuss what we can do as
improvements, and a picture helps a lot IMO.

For people not familiar with the notation, everything on the first
part of each table, together, forms the primary key. Don't be scared
about indices formed of 4 values. :-)
The icons just represent the type of the data, FK means Foreign Key,
and AK in this case represents the non primary Unique Keys (AK stands
for Alternate Keys, but we don't have any non unique key).
For the linkings, circle means 0, -- means one, and the symbol with
the 3 dashes means many.
Dashed lines mean non identifying relations, ie, a relation that adds
a value that isn't used to identify the record.


Sadly litesql doesn't seem to be ready for us, so I fear we'll end up
either using qt stuff, that doesn't actually help much, or coding the
support ourselves (in a better way, hopefully).

["amarok-intended.pdf" (application/pdf)]
["amarok-intended.ER1" (application/octet-stream)]

_______________________________________________
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel


[prev in list] [next in list] [prev in thread] [next in thread]