[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ojb-user
Subject:    [OT] Surrogate/Artificial Primary Keys and large databases
From:       Colin Kilburn <colink () accesstec ! ca>
Date:       2004-04-27 21:00:24
Message-ID: 408EC9E8.3040309 () accesstec ! ca
[Download RAW message or body]

Hi All,

I regularly use surrogate/artificial/auto-increment/meaningless primary 
keys for most of my tables.   While I've only been a full-time developer 
for about 6 years, I have seen this as commonplace and certainly not 
unusual.   I also find they map nicely to the concept of Identity in O/R 
mapping.  

I've recently encountered a customer whose only exposure is 12 years of 
SAP.   From what I understand, the concept of using anything but 
"natural" keys is completely foreign to them, and they think the idea 
that an automatically generated meaningless sequential number is 
"cutting edge" and "unproven", as though I invented the concept.   
They're concerned that it won't scale to very large databases like 
they're used to seeing, such as Coca-Cola's customer database.

My question is this:   can anyone out there name a big company / very 
large database that makes use of auto-increment primary keys?   I'm 
pretty sure this is all I need to make them comfortable that it's 
"proven" and "works with very large databases".    Or am I naive to 
think that a single-column artificial primary key can be a "good thing", 
even or especially with many rows?    I understand that there are pros 
and cons to each style, I'm just looking for an example of a "proven" 
implementation to put my customer at ease.

Please share any experiences with this or even as to how to convince 
someone that the sky won't fall if I use them.

Thanks in advance,
Colin

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]