Re: Form saving, db question ?
Lew wrote:
Actually, I was trying to get at why he was using ID specifically.
The answer "it's the primary key" is flat-out silly - that's circular
reasoning. It's not the primary key because it's the primary key.
WHY is it the primary key? What does it *mean*?
If the answer is "nothing in terms of the problem domain" (vlado - you
need to know what "problem domain" means) then the logical analysis
should eliminate ID and look at the *real* primary key - the one that
identifies the thing described *in terms of the domain of discourse*.
A database table is a representation of the problem domain - it
doesn't drive the definitions, it reflects them.
Arne Vajh??j wrote:
That is what about half the DB people thinks.
The other half thinks exactly the opposite.
That's not at all accurate, though I'd be interested in the statistical basis
for your observation.
The only way I can take the meaning of "exactly the opposite" is that you are
suggesting "half" of "database people" think that the problem domain should
represent the database. I have never in my decades of reading about database
design encountered anyone who suggested the opposite of having the database
model the problem domain, or even deprecated the importance of the unique
attribute collection that defines an entity in the business-domain model.
I'm familiar with the controversy over sequenced surrogate keys vs. not using
them, but no one I've read in that debate has ever suggested that the tail
should wag the dog. /Au contraire/ the proponents of surrogate keys I've read
suggested that surrogate keys help to model the problem domain, and protect
against volatility in the "natural" key. (See the Developerworks article
mentioned /infra/.)
Furthermore, if one does not analyze the problem domain for natural keys, one
cannot properly assign sequenced surrogate keys to the rows, and will risk
update anomalies.
<http://en.wikipedia.org/wiki/Third_normal_form
manages to explain 3NF quite clearly without once resorting to sequenced
surrogate keys.
The ACM article at
<http://www.bkent.net/Doc/simple5.htm>
goes through five normal forms without once resorting to sequenced surrogate keys.
Same with
<http://support.microsoft.com/kb/283878>
The Developerworks article at
<http://www.ibm.com/developerworks/web/library/wa-dbdsgn1.html>
discusses how to pick keys and the motivations to use surrogate keys
responsibly. They provide a balanced viewpoint, but are careful to point out,
"As part of the plumbing, the surrogate key has no need to ever be visible
outside the DB. In particular, it should never be revealed to the user. ... If
a business need arises for providing the user with a unique identifier to a
particular dataset, this identifier should be considered real /business/ data
and kept separate from the plumbing." [emph. original]
--
Lew