On Feb 27, 1:15 pm, "nate" <[EMAIL PROTECTED]> wrote: > Yes, I've read the article, and have been slowly hacking away at a > counter-article for a few months now. Wake up people, it's 2007, and > multi-column primary keys are *still* a dumb idea. >
Here, here! compound primary key constraints are *business* constraints not *application* keys. I for one am quite happy to add a single integer column in order to make good use of Cake. I frequently have this discussion with other Oracle devs who seem to think that invoice_id and line_num are a primary key on invoice lines. Their argument is that there are likely to be billions of invoice lines - but so what? As you say: "Welcome to 2007..." Keep us posted Nate on your article. It it helps, I think the guy is confused between: System Keys (ROWID in Oracle, Tupal [sp?] in PostGres etc - these change on update or replication) Application Keys (single column Primary Key constraints - in practice, these are immutable) Business Constraints (Unique Keys, Compound Primary Keys etc - these frequently change on update) Now, if you want to *know* which record you're manipulating, which are you going to use? ~GreyCells --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
