[
Lists Home |
Date Index |
Thread Index
]
Rick
But the primary key in such a case is the one thing that establishes the
identity of the record over time - it is a surrogate for the real world
thing that the tuple represents. Therefore the thing that is chosen to be
the primary key should be a property that is invariant. If you choose a
property to act as primary key that is not invariant you have two problems.
Firstly the need that you have already identified to update foreign keys
that you know about in order to update them. Secondly, you have the problem
that you do not necessarily know about other uses of the key - information
may already have been sent on to other systems, which leaves you with the
problem of making references over time to something with no firm identity.
Regards
Chris
-----Original Message-----
From: Rick Marshall [mailto:rjm@zenucom.com]
Sent: 26 August 2003 16:32
To: Chris Angus
Cc: michael.h.kay@ntlworld.com; xml-dev@lists.xml.org
Subject: RE: [xml-dev] A standard approach to glueing together
reusableXMLfragments in prose?
chris
ok, shoot the example - that's why most use customer numbers. however it
shouldn't be necessary if the name is a primary key - in fact the
customer number and name then become candidate keys and you have to
select one as the primary key - redundant and not normalised properly :(
i coined my terminology around 1980 .....
cheers
rick
|
