Re: Artificial Primary keys

mrussell_at_beeb.net (Michael Russell) wrote in message news:<c69419da.0201240632.70d31c2e_at_posting.google.com>...
> 71062.1056_at_compuserve.com (--CELKO--) wrote in message news:<c0d87ec0.0201231034.53f2b017_at_posting.google.com>...
>
> 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

   And something additional that hasn't been mentioned yet, in applauding the join response time gained by using generated surrogate keys, be sure to offset that with the additional cost & maintenace of maintaining a redundant unique index on the table when there is already perfectly valid one that 99% of the users will actually be using in queries. (employee-id, start_date). Received on Thu Feb 07 2002 - 20:46:01 CET