Re: ID field as logical address

"JOG" <jog_at_cs.nott.ac.uk> wrote in message news:b766171d-7b30-4251-8c46-b799946a8277_at_l28g2000vba.googlegroups.com...
> On Jun 6, 5:50 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
<snip>

> > It is not essential. Language terms can denote different things at
> > different times. "The President of the United States" is Barack Hussein
> > Obama now, but was George Walker Bush just five months ago.
>
> Those are not merely 'language terms'. The "President of the US" and
> "Barack Obama" are different things, with different properties. The
> fact that they currently happen to coincide is what is confusing you
> (imo of course).

I have to disagree. The Office of the President and the President are two distinct things. The President is a person--the person that currently holds the Office. If I state, "The President of the United States used to be a United States Senator." It is a true statement and will remain true for as long as Barack Obama holds the office, but five months ago, it was not a true statement because George Walker Bush never was a United States Senator.

<snip>

> >
> > It's not so much an integrity failure. Issuing a delete or update that
> > targets a nonexistent tuple is a different kind of nonsense than issuing
> > a
> > delete, update or insert that violates a constraint. I would call the
> > constraint violation an integrity failure, but I'm not sure what name
> > fits
> > the other kind of nonsense.
>
> You've missed the point that we were left (forever) with a tuple in
> the database that was false (concerning the supplier 123 who no longer
> existed). That is the integrity failure, and it is irrevocable because
> of the poor choice of key. Unless you address how this problem can be
> averted (without intervening updates, which as we have seen may not be
> available), your position must be acceded.

I still think it is a communication problem and has nothing to do with key choice. Choosing a "stable" key merely reduces the frequency of key updates. It does not prevent them altogether. To prevent them altogether, there must be a transition constraint. But under Date and Darwen's databases-as-collections-of-relvars paradigm, it is not possible to declare nor enforce such a constraint.

Constraints shape the Universe. Declaring a constraint that prevents key updates fixes the "meaning" of the set of symbols that comprise an instance of that key. Without the constraint it is possible for that set of symbols to "mean" different things at different times.

> This is not key stability problem--it's not even a database problem: it's
> a
> communication problem. If the direct deposit of your paycheck into your
> bank was delayed because the internet was down, but the automatic bill-pay
> of your mortgage and equity line occurred on time because they're from the
> same bank, then you'll be charged bounced-check fees for your mortgage and
> equity line, and late payment fees for your mortgage and equity line, and
> because you were late on your payments your credit rating will be hosed
> and
> your other creditors may as a consequence increase your interest
> rates--all
> due to a communication problem.

<snip> Received on Mon Jun 08 2009 - 04:41:45 CEST