Re: ID field as logical address
Date: Fri, 5 Jun 2009 02:07:18 -0700 (PDT)
Message-ID: <d8a4cedd-aa4b-420d-89e5-3cd8da98d8d5_at_a36g2000yqc.googlegroups.com>
On Jun 5, 11:41 am, JOG <j..._at_cs.nott.ac.uk> wrote:
> At risk of repeating myself, S# has merely proven to be a bad key
> again - it is clearly an unstable identifier for a supplier (just as
> 'name' was in the 'divorcee' example). This is just another flawed
> schema, not a problem with the RM.
I agree with you, in practice a key that has a probability of change of 10^(-1000000) is far better than one which has 10^(-10). However in theory we deal with a zero or non-zero probability. If we accept that a key value can change (and the relational model accepts that – more over, offers referential actions to help us deal with) then we should accept that a transition constraint check could fail.
For state constraints such kind of problems are gracefully solved by multiple assignments. But how they will be handled in case of transition constraints? The theory would not be complete without that specification. I really hope the next D book (or an article) will clarify things. Received on Fri Jun 05 2009 - 11:07:18 CEST