Re: OID's vs Relational Keys?

-CELKO- wrote:
> I have invented the term "physical locator" to cover things like the
> classic hardware pointers you are talking about, row_id within a table
> structure, hash table values, etc. Anything that:
>
> 1) Is not an attribute in the reality of the data model. in the
> Relational keys are a set of attributes by definition. Nothing to do
> with physical storage.
>
> 2) They are generated inside the machine and depend on the internal
> state of the machine at creation time. Nothing to do with the data
> model or the real world.

I don't believe a hash value complies with this. Hash values are deterministic and do not depend on the state of anything not present in the tuple notwithstanding collision detection/avoidance mechanisms.

> And I do believe in duplicate values, but not duplicate data elements.
> So did Dr. Codd when he introduced a "Degree of Duplication" operation
> in his second version of RM. Codd also defined a surrogate as being
> hidden from users, so things like auto-numbering and IDENTITY do not
> qualify in most products.

Who is the "user" in your view? The dude that codes the application (ie. the user of the DBMS) or the end user of the finished application?

Cheers, Frank. Received on Fri Dec 23 2005 - 00:53:32 CET