Hi Larry, On Tue, 2006-09-19 at 20:51 -0700, Larry wrote: > For almost every project where we used natural primary keys, I've > needed to later add some utility to allow the user to alter them. This > code needs to look accross every table that reference this primary key > and alter it there. Running it without concurrency problems is > difficult and so dealing with the entire issue is just extra work and a > headache. It also introduces another user interface element that I > have to train to users (key changes must be done in single user mode > using this special key change menu item, blah-blah-blah). So a while > back, I switched to never using natural primary keys. I've also heard > that integers are more efficient but it's not the reason I use them.
My reply to Bayle was intended to be didactic, not to argue for one approach or the other, which is why I prefaced it with "Many database professionals" (plus, this is not the right forum). Personally, I tend to deal with them on a case-by-case basis, but I'm definitely not in the "religiously using surrogates" camp. OTOH, I know a guy that thinks sequential keys are almost sacrilegious :-) Joe --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss -~----------~----~----~----~------~----~------~--~---
