> Celko's books are great but surrogate integer PKs are an unavoidable > practice within relational databases, they are a requirement of most > DBAs I've dealt with
Those guys don't even have a faint clue how clueless they are. In fact this very issue is *THE* "litmus test" question I ask people who claim to be software developers or database admins. > as they perform predictably in terms of indexing and space > requirements, Surrogate keys will inevitably produce inconsistent data garbage. And data garbage can kill people, among others. And "performance" is simply irrelevant when the "optimisation" result is data garbage. > especially considering that a PK implies the format of all the FKs > that will refer to it. Typically a UNIQUE constraint is placed on > the "natural" key to prevent dupes. Won't work. Check the index of any decent database design handbook for "overlapping foreign keys". Sincerely, Wolfgang -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
