Re: Relation Schemata vs. Relation Variables

"JOG" <jog_at_cs.nott.ac.uk> wrote in message news:1156163752.697442.161770_at_i3g2000cwc.googlegroups.com...
> Brian Selzer wrote:
>> Identity beyond that provided by a candidate key (that is, a single
>> database
>> state) is in the eye of the beholder:
>
> Identity beyond that provided by the identifying keys is a nonsense. By
> not encoding it you have told the system it does not exist. If this is
> not true who is at fault?
>

How do you tell the system that it does exist? How can you know when you design a system whether a key that appears to be very stable will remain that way? I was called in to fix a problem at a company where management decided to add a prefix to each part number so that they could tell at a glance which plant produced a part. So an identifier that was very stable suddenly wasn't for several days while admin staff were busily updating every part number in the system, and duplicating parts that were made at more than one plant. In the end many reports and the application had to be modified in order to summarize the information for parts produced at multiple plants and to work around the redundancy introduced as a result. During that period the database became corrupt because it allowed changes to occur that shouldn't have been allowed. In this case, preventing those changes was left up to the application, which was not designed to deal with multiple entries for the same part and which remained broken for several weeks--making the problem even worse. It can be surprising how a change that doesn't seem that significant can spiral into a total disaster. The point is, keys that appear to be very stable can change for the stupidest reasons, and constraints should be definable and enforcible in the database--including transition constraints. The designers of a system are making a gross assumption about the stability of those keys if they think that what is stable today will remain stable tomorrow. Received on Mon Aug 21 2006 - 19:24:55 CEST