The answer to your question depends on what you actually want out of your database. If you're looking for a dumb storage for an object set, as most ORMs act, then having a single primary key for each table is vital because each row is a distinct object. There's no point fighting this, just add a serial/auto_inc column or whatever your ORM likes and go with the flow.
If on the other hand, you'd like a relational database that can use its knowledge of the dataset and schema to optimise the insertion and retrieval of information in an intelligent fashion, then composite PKs are a very effective tool. They're not a tool you use everywhere, but where you want them, they do wonders and I'd certainly never give them up myself. I don't use ORMs at all. They're inefficient at best, and hideously inefficient at worst - even relatively smart ones like SQLAlchemy. The specific rule "Those who don't understand X are doomed to reinvent it poorly" has never been more relevant than when applied to SQL. Regards, Richard. On 15 March 2010 16:11, Aaron Cooper <[email protected]> wrote: > I've seen them alot, worked with them rarely. I was just hoping to open a > discussion with people working with experienced DBA's regarding today's > standing on the use of composite primary keys. > > I ask, as I have been given a schema to work with, and will be using a > framework for development. CakePHP doesn't support composites at all, and I > read alot of troubles in other frameworks to work around them. (to the point > of hand rolling queries) > > Call me lazy, but it just seems to me that in most cases, a singular PK can > be found for pretty much any table. But are they are must in certain > situations? > Regards > Aaron Cooper > > -- > NZ PHP Users Group: http://groups.google.com/group/nzphpug > To post, send email to [email protected] > To unsubscribe, send email to > [email protected] -- NZ PHP Users Group: http://groups.google.com/group/nzphpug To post, send email to [email protected] To unsubscribe, send email to [email protected]
