Re: Natural keys vs Aritficial Keys

From: paul c <>
Date: Thu, 28 May 2009 15:49:22 GMT
Message-ID: <6oyTl.28362$Db2.4314_at_edtnps83>

Walter Mitty wrote:
> "David BL" <> wrote in message

>> The ORM idea makes the blunder because it assumes incorrectly that the
>> values within a set can be identified independently of their value.
>> ORM wants to make this assumption so that a variable that records a
>> set of values can instead be interpreted as a set of variables.

> The last several exchanges in this thread have gone over my head. Oddly
> enough, this last paragraph brings the discussion full circle, back to where
> I started.
> Consider a set of tuples. Or maybe a set of current states of
> tuple-variables. (That's the part that's over my head.) Now consider a set
> of simple identifiers, called ID. ID could have values like 1,2,3,... or
> any other sequence that can be auto generated and guarantees identity. (The
> word "sequence" rather than the word "set" is intentional here.) Now merge
> ID with the original set of tuples, by arranging the set in an some
> arbitrary sequence. now associate the first tuple with the first ID, the
> second tuple with the second ID, etc. etc. until every tuple in the set has
> been identified with an ID. Call this the tagged set of tuples.
> Now what you have is a set of tuples where the ORM assumption makes sense,
> after a fashion. The values in the original set can now be identified
> independently of their value, because each of them has been tagged with
> this artificial key called ID, one that can be used for identification
> purposes.
> So maybe the practice of starting every table with a field called ID, and
> one that's autogenerated, obeys some sort of instinct. Maybe ORM obeys the
> same instinct. And maybe the tendency to make tools that require simple
> keys obeys the same instinct. If that turns out to be true, the next two
> questions for me are obvious: do I want to obey this instinct myself? And,
> if I don't, how to I want to dialogue with somebeody who does?
> Incidentally, I think I understand just a little bit about the difference
> between a variable that records a set of values and a set of variables. In
> the second case, if I read it right, the cardinality is immutable. In the
> first case, the cardinality is variable. If I reread what I just wrote in
> the light of this, some of it needs rewording.

The RM outlaws some 'instincts', but not that one, so why bother 'tagging' when relation attributes provide all that is needed? Why invent arbitrary operators when the RM already has more general ones? (two cynical reasons would be ignorance and 'jobs for the boys').

The RM has no way, and doesn't need a way, to distinguish attributes conceived by humans from ones that a machine generates. The ORM people generally have failed to recognize the Information Principle, not to mention what is more than an historical coincidence, the rise of OO programming language popularity at the same time as wide-spread adoption of gui interfaces, custom 'OO' methods were an obvious way to program gui's even though they had very little to do with the simulation motives of some of the OO language originators. Generally the OO people are too caught up in their own legerdemain to see the forest for the trees and they are the not surprising allies of the schema diagramming crowd because both groups are disconnected from actuality, no matter how much they natter about reality.

The phrase 'natural keys vs. artificial keys' is actually a slur, it.would be more productive to ask whether "human keys or machine keys?" is a question with any usefulness other than how to implement. Received on Thu May 28 2009 - 17:49:22 CEST

Original text of this message