Re: Artificial Primary keys

71062.1056_at_compuserve.com (--CELKO--) wrote in message news:<c0d87ec0.0201231034.53f2b017_at_posting.google.com>...

>
> But it costs you verifiability. How do you know that number 123 is
> really "John Smith" and pay salaries and taxes to him? Did you put
> him in the database twice? Did someone else get his number? Who
> knows? With SSN, which you have to have anyway, you can verify it
> with other documents and the tax boys.
>
> >> However, the real-world unique id for an Assignment is 'employee-id
> || start-date'. Other people's thinking in this area is that a short,
> numeric key is easier to maintain (marginally) and it will perform
> much better for the joins that are to come. <<
>
> Join performance is a Red Herring these days. Most computers have a
> long word size, so we are not back in the days of 16 bit minicomputers
> when Sybase was just starting on UNIX on DEC PDP-11s and Data General
> Novas were the neatet thing on Earth. You really have to have a
> really long, ugly key for it to slow things down (SQL Server GUID, for
> example). Your algorithmic key is easy to verify, unique within each
> job to which an employee is assigned. I like it.

Celko,

Thanks for your reply. I especially agree with the point of "verifiability" that e.g. 123 refers to "John Smith" ... especially when recently debugging programs with a level of indirection masking such simple attributes! "Is this the right record or isn't it?!"

I've no axe to grind as far as prefering "natural attributes" to "surrogates" as keys -- but "surrogates" leave me a little uneasy because of their anonimity.

Thanks again,

Michael Received on Thu Jan 24 2002 - 15:32:02 CET