Re: [Info-ingres] Re: is there an equivavlent to auto_increment in ingres ?

At 8:07 PM +0100 7/19/05, Roy Hann wrote: 
"Michael Leo" <mleo@xxxxxxxxxxxxxxx> wrote in message
news:mailman.1121792403.2069.info-ingres@xxxxxxxxxxxxxxxxxx

 These "engineering" problems are just a few examples of a great
 iceberg of issues that make the academic statement that "surrogate
 keys are wrong" just plain nuts.


Mikey, as I know you know, I make many of the same arguments you do, in my
"Key Points About Surrogate Keys" paper.   So plainly I agree that surrogate
keys can be useful--when used with discipline, understanding, and very great
reluctance.

When an entity originates in a system, of course the system can generate a
reference number for it.  For that reason a billing system can, and must
generate invoice numbers.  (But strictly speaking, that is a synthetic key,
not a surrogate key.  Surrogate keys are invisible to the user.)


I strive to make surrogate keys invisible to the programmer.  Not always
possible, but desirable.

Where I disagree with most database designers is that I would use a
surrogate as a last resort, while many seem to resort to it first.  And that
is just plain nuts.  For one thing, it usually creates an entirely spurious
illusion of certainty where none can really exist because it has masked
errors in the analysis of the business process or the business model.  Just
because it makes failures of identification undetectable, that doesn't mean
they've gone away.


Oh, I agree with all of the above.  Especially the last point about
masking errors in analysis.  That is why it takes a lot for me to make
a surrogate key a primary key.

Next you'll be lining up with Emiliano to tell me that null-yet-unique keys
make sense! ;-)

Roy 

Nope.  Can't bring myself to believe that.

--
Michael Leo               Java, J2EE, BEA WebLogic,
Caribou Lake LLC          Oracle, Open Source, Ingres,
mleo@xxxxxxxxxxxxxxx      Real Enterprise Applications
.