Re: ID field as logical address

"JOG" <jog_at_cs.nott.ac.uk> wrote in message news:29a0f7bc-9c46-4345-83f4-7455c3e92f24_at_z5g2000vba.googlegroups.com...

> On Jun 5, 2:10 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:

>
> 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. And by the way, an EMP# can change and may indeed be required to change if payroll processing is outsourced. That would make EMP# even less stable than a person's name, since it is usually only women who are marrying or divorcing that change their names, whereas even the men's EMP# might have to change. The stability of EMP# could be even more severely affected if the payroll outsourcing is done piecemeal, such as the employees for one plant or warehouse at a time.

>> , thereby limiting the
>> expressiveness of the model.
>>
>> > > > 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.

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 Sat Jun 06 2009 - 06:50:58 CEST