On 4/04/12 7:06 PM, Durchholz, Joachim wrote:
However any time you have a primary key with meaning is probably
a mistake in database design. You are best trying to avoid this
at all costs unless you are constrained by a legacy system in
some way.

This is common advice, but the topic is controversial.
Even in non-legacy databases, having natural PKs can have advantages:

[snip]

I take your points, but almost anything that looks like a natural key... rarely 
is. Back when I developed systems for other people, I could not count the 
number of times a customer guaranteed that a certain value would never ever 
change. Ever. And of course it did.

People who aren't programmers have a more relativistic concept of "never". To them, getting hit by lighting 
is "something that just never happens". If it happens once every 5 years, that might also qualify as 
"never". To them, your question simply means "so rare as to be not important to their daily lives". 
But of course there is a situation when that EAN isn't unique. When an ISBN is accidentally used twice for the 
casebound and software editions (they should be different). For a programmer unique and immutable have a special 
absolute meaning.

Yes a government tax number or social security number is unique and immutable. 
And that would be true only if your database table was a table representing 
social security numbers. Instead it probably represents 'people' and then the 
correlation becomes far less certain. Do government departments ever make 
mistakes? Do they reassign numbers to people in a witness protection program?


Maybe there are exceptions. I can't think of any. At any rate, once you give yourself 
over to an ORM (Cayenne or anything else), the agreement you make with the software is 
"Give me objects and don't bother me with how they are stored." SQL with a 
primary key or 12 chimpanzees with punch cards, it doesn't matter. Sure you can open the 
hood and tinker with the engine. But if you just want to just drive the car, primary keys 
are not something that should be exposed in your Java code.


Ari



--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

Reply via email to