That is something that I have been wondering about recently – how other packages handle this. My context is Siebel. Although it has a concept of user keys – and generally enforces uniqueness with unique indexes – it uses a field called row_id on every table. row_id is used for all foreign keys on other tables and has its uniqueness enforced with unique indexes as well. (If you’re following along in a data model, you will actually see a second field here – conflict_id – that only comes into play with remote database synchronization – ignore it for this discussion.)

I believe that this is generally because what the package designer may have assumed to be unique is not necessarily the case for all customers that will use the software. Even the user key columns frequently are populated with what I would consider a meaningless key – such as a customer identifier.

Indeed – I offer that much of what folks may believe is meaningful data is in fact no different than the “meaningless keys” that Jonathan was referring to. When we want to identify a computer monitor or other expensive piece of equipment, we have to have some way to describe it – so we invent something called a serial number. I suppose that we could also identify it by it’s model #, product plant, production line, production date, and a number representing that it was the N’th one of that model produced at that plant on that line on that date – but no one does that do they? Everyone assigns a serial number and puts it on a sticker on the back. How is that really any different from from the meaningless keys being discussed here? The only difference is that we tell people about it and use it in business processes. Same thing for customer ids…

So – with regards to SAP and other packages (this is not to be argumentative – I genuinely want to know):
1. Are you saying that they don’t use an artificial thing like row_id in Siebel?
2. Do they use things like serial #’s and customer id’s that I suggest are really “meaningless”
3. How do they handle data that does not have a generally accepted id – but a very extensive (or possibly non existent!) key otherwise – such as address?

Siebel handles the user key for address in an “interesting” manner that sometimes leads to issues – it concatenates several fields, truncates to 100 characters, never updates that field and hopes for the best… Larger implementations have had to address this issue. It is common for billing and other type of applications of a national scale to generate a “house ID” or something similar – again something that I liken to a meaningless key.

By the way – Jonathan’s condemnation of having to traverse levels in the data model doesn’t apply in very many cases in practice with Siebel. Where it does, they have usually already denormalized the data.

I resolutely come down on the side of meaningless keys generated by sequences, but not for technical reasons.

Having inherited a total disaster of a db, which was a migration from an equally disastrous sql server db, I had to deal with the beast. Documentation was non-existent, and so I arbitrarily added an ‘_ID’ PK to every table, across the board. Because I knew that I didn’t know, what this achieved was to definitively eliminate uncertainty about keys, forever. Time and again, this has paid dividends, when we have unearthed information which shows that the supposedly ‘natural’ keys were based on flawed assumptions and designs. If you’re in uncertain undocumented hell, always go for surrogacy.

Second, our users have just decided that they must be able to split the db into six, work on each section, and then bolt it back together again. Using the standard trick of juggling sequence starts and increments to avoid pk/fk collisions, means that I can do this easily. I’d love to see someone code that up with natural keys.

Once again, the best protection against uncertainty and lunatic user requirements is meaningless drivel pk’s. Since I’ve never ever seen a fully documented database, can anyone tell me what it’s like to work on one?

I’m not inclined to believe your “Fact is:” statement, having seen a few applications that work reasonably well and don’t follow the “meaningless key” strategy – but it could, of course, depend on you definition of “successful” and “commercial”. I recall a conversation I had with the head of marketing of the world’s most popular application in field X (name withheld to avoid easy idenfitication of product). It went like this:

“How come this is the most succesful application in the business, the design is appalling and the performance is abysmal”.
“Yes, but you should see the opposition”.

But even if your statement were true, it would still be based on a logical error. Even if every currently successful commercial application used meaningless keys that wouldn’t mean they were successful because they used meaningless keys – think Betamax; and being “commercially successful” doesn’t mean they should be taken as role-models for an in-house development.

The “disk is cheap” mantra is, I agree, almost invariably a hand-waving exercise designed to distract attention from bad design and worse progamming. But in my experience it’s not usually the use of real keys that creates the demand for more space.

Meaningful keys are very nice in theory but cause incredible space overhead in any practical application with any data volumes beyond a few thousand and any keys longer than a coupla bytes. And as previously noted, better never have to modify a value in a key: the cascading is atrocious…

Before anyone mentions the ubiquitous “disk is cheap” mantra: oh no, it most definitely is not.

Fact is: there is not a SINGLE successful commercial application design in the market that has made use of meaningful keys. Not one! They all, without exception, use the other kind. And for a very good reason.