Warning: magic_quotes_sybase is not turned On in the php.ini file. This is bad.
Warning: magic_quotes_gpc is not turned On in the php.ini file. This is bad.
Article > Meaningless Primary Keys, Arrogance
Description :: You're wrong, I won't tell you why, but the results will be disastrous. *makes "spooky fingers" gesture*

You know what I hate? I hate unjustified, condescending bullshit.

During the last few days, I've been involved in a discussion over at The Daily WTF about the pros and cons of using meaningless primary keys when designing a database. Most involved in the debate seem to hold the view that meaningless primary keys are at the very least acceptable, if not ideal. There are a few hold outs, though, with the idea that meaningless primary keys are bad, bad, bad, and they've been sure to let us database philistines know how unwashed we really are.

Granted, I am no database expert. All I know I've learned from Mr. Hanchey at OBU in my Systems Analysis class or from my own, short experience. But all of that, limited as it is, has taught me that, most of the time, meaningless primary keys are the way to go when designing a database. They just make things, such as joins and foreign key references, easier, and you never have to worry about the business rules that govern your primary keys changing their mind three years down the line and screwing everything up. Why? Because business rules don't govern your primary keys! Meaningless primary keys exist only as primary keys and as nothing else; they mean nothing to anybody and thus will never need changing, and they do nothing but uniquely identify each row in each table and link rows in one table to rows in another table. A meaningless primary key is as pure a primary key as one can have. At least, that is what my education and my experience have taught me.

To hear the "natural" primary key proponents tell it, meaningless primary keys are fundamentally incorrect, according to the relational database model, and will certainly lead to disaster in any database that is designed to use them. The problem I have with this is that none of them, not a single one, can tell me exactly how meaningless primary keys are fundamentally incorrect, nor can any of them show me how meaningless primary keys necessitate future disaster.

They all seem to be content with stroking their own...erm...egos by talking about all the books by Date and Codd they've read. Of course, they can't give me any specific quotes from any of those books that support their point of view when I ask for them. They'd rather just tell me story after story of how some ass clown screwed up their database and used meaningless primary keys (note the use of "and used" rather than "by using"), the end result being financial ruin for themselves and their employer. Scary stuff, indeed, but it has no bearing on the topic at hand. Interestingly enough, they won't accept scary stories about how the specious use of natural primary keys has made a database unmaintainable as an argument against natural primary keys.

And when you repeatedly refuse to take their "people who use meaningless primary keys make retarded database design decisions" argument as a valid argument against meaningless primary keys themselves, they come back at you with something like, "...buddy, you just don't get it. And that's OK. Some day, you will .... I gave it my best shot" (actual quote from the DailyWTF debate). Frankly, their best shot sucks hard.

I like to consider myself a teachable guy. If I do things one way, and someone comes along an shows me that the way I'm doing things is wrong, I'll swallow my damn pride and change the way I do things. But if someone comes along and says, "Uncle Midriff, the way you're doings things is wrong. It shows a blatant misunderstanding of the fundamentals of your field, it's irresponsible unto negligence, and it will result in great loss to everyone involved. If you were as smart and as well read as I am, you'd realize this" and then can't or won't provide a single argument, example, or anything else to back up that claim, I'm going to get fucking pissed!

This subject is very important to me, as about a third of what I do at work deals with databases. I realize I'm new at this, and I desperately want to do things the right way. So when someone with more experience comes along and tells me what I'm doing is just awful, it shakes me to my core. I've actually lost sleep over this. If they'd just tell me why what I'm doing is wrong, I could change my ways and move on. As it stands now, though, when I start designing a new database in a month or so, I'm going to have to go with what my education and experience have taught me so far, all the while waitng, thanks to the withholding natural primary key crowd, for the other shoe to drop.

I've just about given up on any of them helping me out, so I've ordered a book (An Introduction to Database Systems, Eighth Edition [Hardcover] by Date, C.J.) by one of their oft-referenced authors in the hope that I can get a deeper understanding of this issue, and perhaps some closure and confidence (however, if I ever become the over-confident bastard that some of these people are, I give everyone who reads this permission to shoot me). But until that book arrives, I sure wouldn't mind an example or two, or perhaps even a reference to the specific chapter of the book that I should read, to help me understand the natural primary key argument.

Continued at top
Owned by UnkieMidriff - Created on 07/15/2005 - Last edited later the same day

Warning: Creating default object from empty value in /home/www/pseudotheos.com/html/code/object.inc on line 1343
Sort 13 items by: Ranking - Owner - Last update - Type - Title

Warning: Creating default object from empty value in /home/www/pseudotheos.com/html/code/object.inc on line 1343

Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/www/pseudotheos.com/html/code/object.inc on line 4271