Search Postgresql Archives

Re: Am I supposed to be all scared of compound primary keys?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 2010-05-01 at 19:25 -0700, Mike Christensen wrote:
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!

I'm not familiar with this project..  That said  it seems they have some automated SQL updating/insert/relation building going on in the classes.  Nothing more than simplifying the class initialising of .net ADO record sets which are overly complicated.

It seems  the class automation can not work with composite keys directly to build relation between classes; create SQL commands to up the records, and make sure  within castle framework the composite key has been updated to all the other classes having relations.  

This warning has no impact on any database but a limitation and warning about Castle-project framework itself. 

The database does not care either way.  Given this limitation is within the framework i follow the advice and not use a composite key.     



All legitimate Magwerks Corporation quotations are sent in a .PDF file attachment with a unique ID number generated by our proprietary quotation system. Quotations received via any other form of communication will not be honored.

CONFIDENTIALITY NOTICE: This e-mail, including attachments, may contain legally privileged, confidential or other information proprietary to Magwerks Corporation and is intended solely for the use of the individual to whom it addresses. If the reader of this e-mail is not the intended recipient or authorized agent, the reader is hereby notified that any unauthorized viewing, dissemination, distribution or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and destroy all occurrences of this e-mail immediately.
Thank you.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux