Re: RM VERY STRONG SUGGESTION 4: TRANSITION CONSTRAINTS

You may be turning things upside down.

It is crystal clear that in a D (which does not expose internal details such as ROWID), individual tuples can only be identified using a (/the) key value. Identifying that individual tuples in two distinct database states are about the same real-life object, is then only achievable if the key value hasn't changed.

Trying to overcome this, e.g. by introducing some kind of "objectid" in the data which is "eternally, once and for all" linked to the tuple in question has other serious ramifications. For example, I suspect that UPDATE can no longer be seen as a shorthand for some particular combination of DELETE-then-INSERT, precisely because of this additional objectid.

Besides, transition constraints are, imo, nowhere near as useful as the literature sometimes makes them seem to be. The examples I see of them are always of the ilk "salaries cannot decrease" and "married cannot change to single". But what if "married" does indeed need to go back to "single" because it was the introduction of "married" itself that was wrong in the first place ? What if salaries DO need to decrease because a zero too many had been typed ? Sorry, you made this mistake and you can't correct it ? Sorry, you'll have to keep paying this 10-times-too-big salary and go bankrupt or you'll have to fire your employee ? Come on.

Or "I assume there is some kind of other machinery in place that allows supervisors to do all necessary corrections" ? So the model deliberately does not aim to offer support for _ALL POSSIBLE_ transitions ? Come on. Received on Fri Sep 03 2010 - 15:41:14 CEST