USB hdd support

[Andrew Turner]

No :P

http://en.wikipedia.org/wiki/Foreign_key

A simple amaroK example:
The tags table has, among other things, the ID of the artist for every song.
The artists table lists IDs and the names of all the artists.

The ID column in the artist table is a primary key, because it will be
unique and used to identify the row. It should always continue to
refer to the same row (until it is deleted) - swapping IDs between two
rows, for example, wouldn't be normal.

The artist ID column in the tags table should only have the same value
as one of the IDs in the artists table, which we've already said is a
primary key for that table. This makes our the ID in the artist table
a foreign key, because it should only be one of the values of the
primary key of another table (you have to specify which table and
column when you create the table).

The potential benefit for actually telling the DB the proper
relationships is rather like that of const-correctness in C++, error
checking. It is, also like const-correctness, possible to ignore, but
not a good idea. I believe the two checks you gain are that you would
get errors if you tried to insert a row into tags with an invalid
artist (ie one not in the artist table), or if you tried to remove an
artist from the artists table while some of their songs still exist in
the tags table.

Corrections welcomed.

Andrew


On 01/06/06, Jeff Mitchell <kde-dev at emailgoeshere.com> wrote:
> Quoting Maximilian Kossick <mkossick at gmx.de>:
> >
> > Foreign key constraints are not enforced by SQLite, so I assumed that's why
> > you are not using FK constraints anywhere.  But yes, theoretically the
> > filename should be a foreign key.
>
> Can you explain what a foreign key is, and why the url should be one?
> Feel free to say no.
>
> --Jeff
> _______________________________________________
> Amarok mailing list
> Amarok at kde.org
> https://mail.kde.org/mailman/listinfo/amarok
>