Re: primary key and existing unique fields

From: Jeff Davis <jdavis-pgsql(at)empires(dot)org>
To: Mike Mascari <mascarm(at)mascari(dot)com>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, PgSQL General List <pgsql-general(at)postgresql(dot)org>
Subject: Re: primary key and existing unique fields
Date: 2004-10-26 22:18:00
Message-ID: 1098829080.6589.94.camel@jeff
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Naeem Bari 2004-10-26 22:18:08 Re: Newbie question about escaping in a function
Previous Message Thomas Hallgren 2004-10-26 22:15:10 Re: Bug or stupidity