Hi Aaron I am not a DBA, but I have pondered this problem as well. I can think of only two occasions when a composite primary key might be used
a) the database is large and doesn't support GUIDs (or string fields) as primary keys, so multiple integer or 64 bit integer fields are used instead b) the primary keys are re-used from the primary keys of other tables, so that their combination makes a unique record id. Case B is the most likely scenario, and the one you're probably referring to, where the tables can be changed by adding a single (auto-increment) primary key field. Todd. > 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]
