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

From: Brian Selzer <brian_at_selzer-software.com>
Date: Mon, 30 Jul 2007 04:48:00 GMT
Message-ID: <44eri.25057$RX.13408@newssvr11.news.prodigy.net>

"JOG" <jog_at_cs.nott.ac.uk> wrote in message news:1185444872.730943.83600_at_o61g2000hsh.googlegroups.com...

> On Jul 25, 10:32 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:

>> "JOG" <j..._at_cs.nott.ac.uk> wrote in message
>>
>> news:1185355659.582994.59190_at_k79g2000hse.googlegroups.com...
>>
>> [snip]
>>
>> >> "The right front tire on my car is going flat."
>>
>> >> "The tire with serial number BC324J5367 is going flat."
>>
>> > Ok, first let me say i totally understand what you are saying. Second
>> > let me add that we advocate the same solution of using a surrogate key
>> > to solve any ensuing problems, we just argue about /why/ we are doing
>> > it.
>>
>> > Let me consider the propistions you stated:
>> > Construct identified in the first proposition - "Right Front Tyre"
>> > Construct identified in the second proposition - "Tyre BC324j5637"
>>
>> > These are different things.
>>
>> No, these are not necessarily the same thing. "Different" is absolute,
>> and
>> incorrect because it may be the case that they are the same thing.

>
> My bad, I shouldn't have used the word 'thing' as its so overloaded. I
> meant to say they are different constructs.
>

>> You
>> speak below of "constructs" overlapping, but that just doesn't make
>> sense.
>> Can there be two different "constructs" that occupy exactly the same
>> space
>> at exactly the same time?

>
> Ok, yes, that's exactly what I think. Now I'm not crazy, and I do
> realise for a tyre there is obviously just one set of atoms there, but
> it is our definition of what a tyre /is/ (the construct) that
> overlaps.  These construct-types are _defined_ by how we identify them
> (that being qualative identity not numerical identity of course) - and
> if that identifier changes then we end up with a different instance.
> And if this is unacceptable to our application then we picked the
> wrong construct!
>

It appears to me that you're treating a description of an individual as an individual.

> If we are designing a database, and we pick the wrong construct, we
> then as a consequence pick the wrong identifier, which ends up as the
> wrong key to use, and eventually the database hits a problem when
> things change. Thats why I think its a design issue, rather than any
> flaw in the DB theory.
>

>>
>> > "What", you no doubt cry, "of course
>> > they're the same bloody thing". Well, consider that I also tell the
>> > mechanic:
>>
>> > "The right front tyre on my car always goes flat"
>>
>> > What do I mean: The tyre that is on now, or whatever tyre I put there.
>> > It could be either. One bit of rubber, which I'm continually
>> > repairing, or new tyres that I keep changing. Its probably going to be
>> > the latter in this case, and the mechanic might check my suspension.
>>
>> Actually, in this case it is the tire that is currently on your car,
>> since
>> you didn't say,
>>
>> "The right front tire on my car has always gone flat."
>>
>> But I see what you mean.
>> Clearly "The right front tire on my car has always
>> gone flat." is ambiguous, because it could mean "Every tire that has been
>> on
>> the right front of my car has gone flat." or "The tire that is on the
>> right
>> front of my car has always gone flat." In either case, you can expect
>> the
>> tire that is on the right front of your car to go flat.
>>
>> This illustrates what happens when the only key on a relation schema
>> permits
>> updates. It can't be determined if a new individual is being selected,
>> or
>> if the state of the current individual is now different. The problem I
>> have
>> is with the assumption that it is always the case that a new individual
>> is
>> being selected. This implies that there is a requirement for all keys to
>> be
>> rigid, which is clearly not the case.
>>
>> > The current overlap I have with tyre BC324j5637 is lost. The two
>> > constructs are not the same thing over time, and hence should not be
>> > encoded in a database as such. The design should consider which is
>> > appropriate - the construct of a tyre with a code identifier, or the
>> > construct of a tyre with a position identifier.
>>
>> Are you saying, then, that whenever a key can be updated, there must also
>> be
>> another that can't?

>
> Well, I'd say a key can never be updated. A proposition is removed and
> it is replaced by another, and there is no connection between them as
> far as the database is concerned.
>

I disagree totally. Keys can be the target of an update. Propositions are not removed or replaced: they are assigned a different truth value. And it is the referents of the propositions that bind them.

> All we can say is that two propositions have in common an item that
> they discuss. We can only recognize that item because of its
> identifier. And if the identifier changes there is no connection to be
> made. So we better bloody well pick the right identifer ;)
>

The connection can be found as part of the update.

>> That's certainly one way to solve the problem of
>> identification across database values.

>
> I'm just saying that the attribute that identifies the construct
> uniquely in the real world should be used to identify it in
> propositions (and that we can't rely on contextual and situational
> knowledge that we do in everyday conversation).  I think in general
> database designers are pretty sloppy about such an important design
> points, and it results in a lot of broken databases.
>
> I know you may not be interested but what the hell ;)  - a guy called
> Peter Geach wrote a lot about this sort of thing (and he might be
> worth a google on relative identity), I just don't think its ever been
> applied to database design.
>
> All best, Jim.

[huge snip] Received on Sun Jul 29 2007 - 23:48:00 CDT