| From: | Mark Wilson <mwilson13(at)cox(dot)net> |
|---|---|
| To: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: PRIMARY KEYS |
| Date: | 2003-05-22 20:50:37 |
| Message-ID: | 0A80F29B-8C97-11D7-B6C3-000393876156@cox.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Thursday, May 22, 2003, at 11:43 AM, wsheldah(at)lexmark(dot)com wrote:
>
> Choosing an artificial key is the ideal, according to everything I've
> heard. In one of my database classes, I remember I had a classmate who
> had
> worked with some very large datasets of U.S. citizens, and found that
> there
> were actually duplicate social security numbers assigned to different
> people. Not many, and I don't recall whether the first person had died
> before the SSN was reused, but it really goes to show that they only to
> _guarantee_ a unique primary key is to generate it yourself. Yes, you
> may
> want to put a unique index on your SSN field or other candidate key
> fields
> that ought to be unique.
>
> [snip]
Wouldn't one wish to know, and deal with, a situation where a business
rule -- each person has a unique social security number -- has been
violated? If you're a business doing tax withholding for employees,
isn't this a critical question?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2003-05-22 21:16:41 | Re: ERROR: Memory exhausted in AllocSetAlloc(188) |
| Previous Message | Corey W. Gibbs | 2003-05-22 20:49:19 | ILIKE Problem? |