Re: Natural keys vs Aritficial Keys

"David BL" <davidbl_at_iinet.net.au> wrote in message news:355a5c7c-7357-47ef-a807-629f1a42025e_at_y33g2000prg.googlegroups.com...
> On May 28, 7:56 pm, "Walter Mitty" <wami..._at_verizon.net> wrote:
>> "David BL" <davi..._at_iinet.net.au> wrote in message
>>
>> news:f20bd044-adea-41d5-b301-9dd0f57ed736_at_z16g2000prd.googlegroups.com...
>>
>> > 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.
>
> Yes, I agree it's related to your original post.
>
>
>> 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.
>
> Yes, the ID can be regarded as the "address" of a variable that exists
> in time and space within the database.
>
The fact that ID can be regarded as the "address" of a tuple confirms for me an assertion I made a while ago thatt he ubiquitous use of ID fields is a retreat from content based addressing bacl to location based addressing.

>
>> 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?
>
> I would hope that you won't want to obey this "instinct" and you'll
> try to persuade those around you to do likewise.
>

My inclination is to ignore this instinct, you'll be pleased to know. As far as persuading others go, I do that less and less with every passing day. Why should I destroy myself?

> That being said, there are in fact certain cases where abstract
> identifiers seem inevitable - but I think that's often where recursive
> types are needed in the data model.
>
>
>> 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.
>
> I don't agree here. A variable that records a set of variables
> doesn't normally have an immutable cardinality because variables can
> be added and removed from the set. Remember that the set of variables
> is itself recorded in a variable.
>

I don't understand how your response differs from my earlier comment. I think I said that a variable that records a set of values (which I called the first case) has a variable cardinality. The second case, a set of variables is not, if I read it correctly, a variable. Received on Thu May 28 2009 - 19:05:02 CEST