Re: Use of numeric pseudo-key vs. text key

You make some valid points, but I think David Cressey's March 25 post here titled "Surrogate keys" describes the real world a little better. There will be some cases where you cannot have a naturally unique key, sometimes caused by the errors of human behavior and sometimes unavoidably by the nature of the data.
So how about a hybrid primary key, where you combine a mostly unique natural key with a meaning-free surrogate value. - cb

Srinivas Venigalla <svenigal_at_rochester.rr.com> wrote in message news:YYRw6.12675$8R5.1846448_at_typhoon.nyroc.rr.com...
> There is a plenty of discussion in this group on this topic. you may want
 to
> search using a good search engine like google. But here is my two cents
> worth:
>
> A primary key must be part of the data the table is representing. Good
> examples of a Primary key are: Emp_ID, Product_ID, SS_NO, tel_no, etc.
 They
> are naturally unique keys within the enterprise or the domain.
>
> An auto-incrementing ID, though it satisfies the requirement of a primary
> key, is a wrongway to use it. Those keys do not have any meaning of their
> own. Worse yet, the value of such PK varies depending on the order of
> creation! When you export a table and import, you may not be able to use
> that key at all (it happens on Microsoft products!). Every table in your
... Received on Fri Mar 30 2001 - 05:07:39 CEST