Re: primary key and existing unique fields - Mailing list pgsql-general

From Jeff Davis
Subject Re: primary key and existing unique fields
Date
Msg-id 1098829080.6589.94.camel@jeff
Whole thread Raw
In response to Re: primary key and existing unique fields  (Mike Mascari <mascarm@mascari.com>)
List pgsql-general
> That article makes me want to vomit uncontrollably! ;-)
>
> "Business data might also simply be bad -- glitches in the Social
> Security Administration's system may lead to different persons having
> the same Social Security Number. A surrogate key helps to isolate the
> system from such problems."
>
> The surrogate key isn't solving the underlying logical inconsistency
> problem. It is being used as a work-around to cover one up. I suspect
> the author of being a MySQL user.
>

I think what he's saying is that an application bug, or a business
process problem, should not interfere with your database system.
Granted, two identical SSNs seems far fetched. However, if your business
screws up and you need to change someone's primary key, you've just
violated the principle of a primary key. You better be REALLY sure the
primary key will NEVER change over time for a given record, and that it
really is unique.

An SSN might fit that description, but there are always strange
situations. What if someone sues to have their SSN changed and a judge
orders it? If that's their PK, the social security administration is up
a creek (at least in the DB theory world, it probably wouldn't matter
much in practice).

Regards,
    Jeff Davis



pgsql-general by date:

Previous
From: "Naeem Bari"
Date:
Subject: Re: Newbie question about escaping in a function
Next
From: "Leen Besselink"
Date:
Subject: pg_autovacuum in 8beta-dev3 small bug