9:55 AM - Some people are just plain wrong
dbaspot.com/ingres-database/191160-there-equivavlent-auto_increment-ingres.html
This is a mailing list conversation between several users of the Ingres database about why auto increment primary keys are bad. I disagree with them for many reasons.
- ORM packages require a surrogate primary key. And yes, it does have to be a PK. Thank Cayenne developers for that.
- The basis of their argument is that a PK should be meaningful and a natural primary key. I understand that perspective, but many people are paranoid about exposing meaningful primary keys in web applications. I think it depends on the key and the application if it's actually a problem.
- What they want to use a PK for can be accomplished with a unique constraint. One of them acts like constraints are evil (that's what an identity column is after all). Constraints protect data and enforce business rules from poorly written applicaitons or confused developers.
- I concede that a PK used in this manner is similar to an inode number which they can't even mention by name. There's a reason file systems use them. They uniquely identify a file. Imagine that. Imagine if file system designers thought like this, you could only have one file on the ENTIRE FILE SYSTEM with the same name!
- The craziest point in there was that developers use auto increment columns or guids because that's all they know. Most developers haven't been exposed to formal database theory and DBAs are no longer experts at databases, but rather maintenence workers in the modern .COM era. It's sad as a DBA should actually do real work not little tasks. There is a trend to use database records as objects.. that's the way things are.