On Sun, 5 Dec 2010 20:53:43 +0100, Christophe Danker
<sqli...@christophe.danker.name> wrote:
> thanks for answering. Well, without wanting to open up a general discussion
> on the merits or not of having compound primary keys with one auto-increment
> value, i had other technical constraints in mind relating to perl's
> Catalyst::Model.
I'm afraid i have to open the general discussion anyway.
> I solved my issue by recurring to DBIx::Class::ResultSource's
> set_primary_key("id","b") w/i the Schema resultset and declaring the CREATE
> statement as you indicated.
>
> But why not make autoinc feasible on compound primary keys if only one
> of the keys is of type INTEGER? Is it a design reason or is there another
> obvious reason i can't see?
Because it's not needed, and it's not proper design.
The autoincrement column is a primary key by itself, because it
uniquely identifies every row. From a normalisation standpoint,
there is no reason to add other columns to the primary key, so there
is no reason to implement it in SQLite.
If you need a compound index for performance reasons, you can use
the autoincrement key as the primary key for the table and define a
unique index on the compound key. Is doesn't serve as a constraint
though, because the primary key constraint is more limiting already.
--
( Kees Nuyt
)
c[_]
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
