Re: OID's vs Relational Keys?
- From: "David Cressey" <dcressey@xxxxxxxxxxx>
- Date: Wed, 21 Dec 2005 22:57:12 GMT
"jason.glumidge@xxxxxxxxx" <Jason.Glumidge@xxxxxxxxx> wrote in message
news:1135176559.700113.120710@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> 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.
.
- Follow-Ups:
- Re: OID's vs Relational Keys?
- From: Frank Hamersley
- Re: OID's vs Relational Keys?
- References:
- OID's vs Relational Keys?
- From: jason.glumidge@xxxxxxxxx
- OID's vs Relational Keys?
- Prev by Date: Re: OID's vs Relational Keys?
- Next by Date: Re: What does this NULL mean?
- Previous by thread: Re: OID's vs Relational Keys?
- Next by thread: Re: OID's vs Relational Keys?
- Index(es):
Relevant Pages
|
