cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Kienenberger <mkien...@gmail.com>
Subject Re: Natural primary keys, Was: Cayenne with JSF 2
Date Wed, 04 Apr 2012 14:57:08 GMT
We're not talking about whether or not a SSN uniquely identifies a person.

We are talking about the process for changing up an
incorrectly-entered natural primary key, for whatever reason that
might be.

On Wed, Apr 4, 2012 at 9:36 AM, Durchholz, Joachim
<Joachim.Durchholz@hennig-fahrzeugteile.de> wrote:
> Seems like everybody is looking at the institutions that can't keep their numbers constant.
>
> Give it a break.
> Ordinal numbers of chemical elements cannot change, by definition.
> I may be too optimistic about ISBNs and EANs. Haven't dealt with them and don't know
how reliable their issuers are. I guess if they are using their own numbers in a PK in any
table that's moderately important, they should catch any duplicates before they make it into
the wild. SSNs are issued decentrally, so I'm not surprised they aren't unique; ID cards are
issued centrally and managed centrally, so the risk of getting caught in a goof-up is considerably
smaller.
>
> Oh, and if you're a company caught in the SSN goof-up, using a synthetic key wouldn't
have helped in the least. There is no better ID available when it comes to US citizens, so
if you're using data from external sources, your data will be goofed up anyway.
> Things are different if you never use the SSN in external communication to other databases.
However, even then you'll never know whether the persons with the same SSN are the same (just
changed name and location) or not; there's no better way to identify US citizens, and a synthetic
PK won't help you much to resolve that kind of issue!

Mime
View raw message