Re: Basic Q on superfluous primary keys - Mailing list pgsql-performance

From Greg Smith
Subject Re: Basic Q on superfluous primary keys
Date
Msg-id Pine.GSO.4.64.0704162239300.7058@westnet.com
Whole thread Raw
In response to Re: Basic Q on superfluous primary keys  ("Merlin Moncure" <mmoncure@gmail.com>)
Responses Re: Basic Q on superfluous primary keys  ("Merlin Moncure" <mmoncure@gmail.com>)
List pgsql-performance
On Mon, 16 Apr 2007, Merlin Moncure wrote:

> extraordinary cases do happen, like a company overhauling its numbering
> systems, but such cases can be dealt with by a number of methods
> including letting RI do its thing.

I think the point Craig was trying to make is that what you refer to here
as "extraordinary cases" are, in fact, rather common.  I've never seen a
database built on natural keys that didn't at some point turn ugly when
some internal or external business need suddenly invalidated the believed
uniqueness of that key.

The last really bad one I saw was a manufacturing database that used a
combination of the customer code and the customer's part number as the
key.  Surely if the customer changes their part number, we should switch
ours to match so the orders are easy to process, right?  When this got fun
was when one large customer who released products on a yearly schedule
decided to change the bill of material for many of their parts for the new
year, but re-used the same part number; oh, and they were still ordering
the old parts as well.  Hilarity ensued.

> it is especially unclear how adding an integer to a table will somehow
> magically solve these problems.

If the key is a integer, it's always possible to figure out a trivial map
that renumbers the entire database programmatically in order to merge two
sets of data.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: FK triggers misused?
Next
From: Robins
Date:
Subject: Fwd: Strangely Variable Query Performance