Re: ID field as logical address

"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:TAmWl.31640$YU2.20647_at_nlpi066.nbdc.sbc.com...
>
> "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:
>>> "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. 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.

Oops, I missed your last post. Received on Sat Jun 06 2009 - 07:41:13 CEST