OID's vs Relational Keys?

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.
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).

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.

I'm finding it tough seeing the wood from the trees with different types of databases. Received on Wed Dec 21 2005 - 15:49:19 CET