Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Separate foreign keys with shared ID space

Re: Separate foreign keys with shared ID space

From: --CELKO-- <jcelko212_at_earthlink.net>
Date: 2 Aug 2004 14:56:23 -0700
Message-ID: <18c7b3c2.0408021356.1672895c@posting.google.com>


>> [A PK should have no business meaning] Hmm, I want to see what Joe
Celko says about this one.... <<

Time to do one of my standard rants :)

The main property you want in a key is that it is verifiable in the reality of the data model. Invariant is very nice, but not actually required. Right now, the United States is facing a massive change in retail:

Bar Code Detente: U.S. Finally Adds One More Digit (2004 July 12, NYT By STEVE LOHR): http://www.nytimes.com/2004/07/12/business/12barcode.html?ex=1090648405&ei=1&en=202cb9baba72e846  

For American retailers, whose checkout-line bar-code scanners will be expected to read the global bar-code standard by 2005 Jan 01. Europe won this one. The global bar code standard will be the European Article Numbering Code. It turns out that the American Universal Product Code - which turned 30 years old last month - was never so universal after all.

Are we doomed? No. We just do some ALTER DOMAIN and ALTER TABLE staetments, get a mag tape from my suppliers and keep going. Why do all these standard codes work? Because there is a trusted outside verification of the codes with internal validation.

That validation is possible **only** because the codes carry business meaning in them -- the first set of digits is the country of origin and the manufacturer. Within those areas, people familar with the particulars for each company can guess the codes (United States, P&G, cleaning products).

An exposed surogate is usually a physical locator like IDENTITY, some kind of auto-increment, or an actual disk address. They do not port, even from release to release of the same product. They are a pathetic attempt to mimic pointer chains from the old IMS and IDMS databases, but when they get out of synch, there are no routines to re-build the pointer chains.

If there is a natural key, they are redundant and dangerous -- update one but not the other and see what a mess you have. Received on Mon Aug 02 2004 - 16:56:23 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US