Re: A pk is *both* a physical and a logical object.

"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:oXdni.23174$Rw1.4623_at_newssvr25.news.prodigy.net... [snip]
>> You can call what the user issued an update, if you care to, but what
>> really happened is that an individual, identified by the before value of
>> the key, was deleted, and a new individual, identified by the after
>> value
>> of the key was inserted. The fact that the old value and the new value
>> used
>> the same storage ("row", if you like) is irrelevant. They are
>> different
>> values, and they designate different individuals.
>
> Not so. Consider the following statement:
>
> I moved the widgit with lot number 203 at location 22 to location 44.

What is the so-called "individual" here? The widget, the lot number or the location? You've told us the key is the entire header, so it is irreducible, so none of these is inescapably unique in this table.

> Now assuming that there can only be one widgit from the same lot at a
> particular location, then the definite description before the update,
>
> the widgit with lot number 203 at location 22
>
> refers to the same widgit as the definite description after the update,
>
> the widgit with lot number 203 at location 44.
>
> If there is also a rigid designator, then the situation becomes clear:
>
> before the update, these all denote the same individual:
>
> the widgit with serial number 123 and with lot number 203 at location 22
> the widgit with serial number 123
> the widgit with lot number 203 at location 22
>
> which is the same individual as these:
>
> the widget with serial number 123 and with lot number 203 at location 44
> the widget with serial number 123
> the widget with lot number 203 at location 44
>
> after the update.
>
> So, if relation widgits {lot_number, location}
> has a tuple {lot_number=203, location=22}

How the heck does this tuple represent *anything* about widget 123 (or any other particular widget) if the serial number isn't an attribute? The only way it can do that is if you first assert your entire relation represents propositions about the widget with serial number 123 exclusively. That's fair enough and I'd have no problem with it, but you aren't saying that.

> and an update is issued:
>
> UPDATE widgits SET location=44 WHERE lot_number = 203 AND location=22
>
> Then the resulting relation has a tuple
>
> {lot_number=203, location=44}
>
> that refers to the same individual as the tuple
>
> {lot_number=203, location=22}
>
> before the update.

I am now satisified that you are talking nonsense. Erudite-sounding nonsense but still nonsense.

Roy Received on Wed Jul 18 2007 - 10:03:48 CEST