Re: ID field as logical address

On Jun 6, 5:50 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> "JOG" <j..._at_cs.nott.ac.uk> wrote in message
> > On Jun 5, 2:10 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> >> "JOG" <j..._at_cs.nott.ac.uk> wrote in message
> >> <snip>
> >> > 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 didn't say it was a problem with the RM.  I said it was a problem with
> >> Date and Darwen's notions that a database is a collection of relvars and
> >> that insert, update and delete are shortcuts for relational assignments.
>
> >> You're underscoring my point, by the way, which is that adopting those
> >> notions requires that every instance of every key be a permanent
> >> identifier
> >> for something in the Universe of Discourse
>
> > Yup, if you talk about something in a proposition use a stable
> > identifier for it. It's not just desirable, but essential. Use a nice
> > stable EMP# not a person's name.  It is about integrity not
> > 'expressiveness'.
>
> 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).

It is /essential/ one knows which of those things one wants to keep track of in order to pick a key that will be stable over time, and hence construct a schema that will maintain integrity over time. If you are concerned with the "person" then that should be the chosen key, and their "post of office" will change over time. If you are concerned with the "post of office" then that is the key, and the "person" holding that position will change over time.

> >> > > > Anyhow here's an important question:
> >> > > > Q. What happens in Brian's model when that transition history it
> >> > > > relies on can't be determined?
>
> >> > > What transition history are you referring to? A transition is an
> >> > > assertion
> >> > > that states, in the context of what has since the last update and up
> >> > > to
> >> > > now
> >> > > been the case, exactly what is now different and how. There is no
> >> > > reliance
> >> > > on history, since the context of both the current database, which
> >> > > states
> >> > > what has since the last update and up to now been the case, and the
> >> > > transition are the same.
>
> >> > What would happen if noone knew that supplier 123 had become supplier
> >> > 456 (i.e. there was no fact available representing that change, so
> >> > nothing that could be used in an update)?
>
> >> If the user didn't know that fact, then they wouldn't have issued an
> >> update
> >> stating that fact.  They would have attempted to issue an update
> >> targetting
> >> supplier 456, and the update would of course have been rejected.
>
> > This is the crucks of the matter. You'd then be stuck with a fact in
> > your database that is false. Why the integrity failure? Because a
> > poor, unstable key was used. There is no solving this with rowid's, or
> > any other kind of shims.
>
> 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.

>
> 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.
>
>
>
>
>
> >> > You always pick examples where there is someone to ask in order that
> >> > some disparity in identification can be ameliorated, but there are
> >> > many situations where this information may simply not be available, or
> >> > even exist at all. It therefore simply has to be all about picking
> >> > good reliable keys.
>
> >> If it is possible for a prime attribute to be the target of an update,
> >> then
> >> one must assume that it will.  Whenever it should not be possible, there
> >> should be a transition constraint that prevents it.  Of course, if one
> >> adopts Date and Darwen's notions that a database is a collection of
> >> relvars
> >> and that inserts, updates and deletes are shortcuts for relational
> >> assignments, then it isn't possible to define let alone enforce such a
> >> constraint.
>
> >> Question: what if the entire heading is the key.  Should updates be
> >> prevented altogether for such relvars?
>
> > Aye.
>
> I think that's a severely limited and limiting point of view.
Received on Sun Jun 07 2009 - 15:30:23 CEST