mike@xxxxxxxxxxxxx (Mike Christensen) writes: > I have a table that stores a user ID and a subscription type, and this is > really all it needs to store and any pair of values will always be unique. In > fact, I think this pair should be the primary key on the table. However, I'm > using Castle ActiveRecord which says at: > > http://www.castleproject.org/activerecord/documentation/v1rc1/usersguide/ > pks.html#CompositePK > > And I quote: > > Quick Note: Composite keys are highly discouraged. Use only when you have no > other alternative. > > I get the feeling they're discouraged from a SQL point of view, but it doesn't > actually say why anywhere. Is there any good reason to avoid using composite > keys on a table? Why waste the space of an extra key if you don't have to? > Thanks! They're discouraging it from an "interacting with our particular object/relational mapping" perspective. They have a fair bit of explanation on that web page, which seems to point at composite keys being something they found was, within their particular framework, more complex to support than "unnatural keys." (They characterize composite keys as "natural," so presumably kludging in a non-composite key is the "unnatural" thing :-).) There are a number of "ORMs" which have a tough time coping with composite keys, but that's an ORM problem, not an SQL problem. -- It is considered artful to append many messages on a subject, leaving only the most inflammatory lines from each, and reply to all in one swift blow. The choice of lines to support your argument can make or break your case. -- from the Symbolics Guidelines for Sending Mail -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
