Re: OID's vs Relational Keys?

"jason.glumidge_at_gmail.com" <Jason.Glumidge_at_gmail.com> wrote in message news:1135176559.700113.120710_at_f14g2000cwb.googlegroups.com...
> I have been reading an article by C.J.Date - "Object Identifiers vs.
> Relational Keys" in Relational Database Writings 1994-1997, and while
> I'm not really an OODBM's fan, there are a few things in it that I've
> found confusing:
>
> 1) The first was that Date adamantly and repeatedly states that OID's
> are pointers. Now I am really foxed by this - as far as I've ever been
> concerned a pointer is a variable that stores a memory address. So how
> an earth can an ID be such a thing? If anything an OID is more like the
> memory address that a pointer stores. But even then surely that is a
> misleading comparison, as a memory address is a fixed physical
> location, wheres an OID is location independent.

I'm probably not the best person to interpret CJ Date, especially on this issue.

On the physical level, I agree with you. A pointer has the effect of "pinning" the data structure pointed to in the following sense: if the data structure is shuffled in the address space of the pointer, then the pointer becomes invalidated.

Of course, there are pointers embedded in index structures, but these pointers are created by and managed by the DBMS. The DBMS can update them when the data structure gets shuffled.

At the logical level, CJ Date's comments make more sense. An OID conveys no more information than a pointer would have. But this question can be raised for any form of surrogate key at all. For that matter, it can be raised about any "artificial key", such as Social Security Number, whether that key is assigned inside the DBMS, or inside the application, or externally by the Social Security Administration.

>
> 2) Date sees no worth in a distinction between identity and equality,
> stating that it is a nonsense that "two objects that look the same to
> the user (meaning the user has no way to tell them apart) might in fact
> be distinct." going on to say that there is no use for "duplicates". My
> first impression is that this seems to happen all the time in the real
> world, where while we know full well two things are distinct but do not
> currently possess the attribute that defines this difference. Or there
> are two items which are identical in all their defining attriubtes but
> are still unique (their location is different for instance, which we
> can't continually record).
>

I wonder whether DNA analysis can determine which of two identical twins can be placed at the scene of the crime. I doubt it. This may seem a frivolous point to raise in this context, but it's not. There is no definitive list of "natural" attributes that can be used for identification. This is always subject to later review in thelight of later discovery.

> Now we all employ surrogate keys to enforce this distinction, but this
> is a value we've just artificially constructed, not part of the real
> items uniqueness. While the mechanism is different (and I agree with
> Date on the logistical differences) this seems to just be giving the
> tuple an identifier, again to allow a distinction between identity and
> equality (two items in an RDBMS are equal if everything apart from
> their surrogate id is the same), that he originally objects to.
>

It is however, important, IMO, to distinguish between identifying the tuple and identifying the object (or entity) that the tuple describes. Received on Wed Dec 21 2005 - 23:57:12 CET