Dann Corbit wrote:
When the data changes, the problems generated are not just due to
repercussions related to the child and parent tables related through the
primary key.
Someone has an invoice, and they call in with a question. A combination
of their name and address was used as a primary key. They moved, and
sent in a forwarding address. The DBA was smart enough to design the
database to cascade results, so that there are no orphan records and we
have not compromised the structure of the database.
The customer calls in with a question about an old invoice.
"We have no record of that transaction."
Aside:
Even if not using name+address as a primary key, a separate record
should be kept of these details *at the time of the invoice* otherwise
you'll never be able to match up a printed invoice with its digital
source. Usually of course this is by inv_name, inv_address columns in
the invoice header, but it could be by some fancy temporal versioning on
client details.
--
Richard Huxton
Archonet Ltd
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
