Re: Natural keys vs Aritficial Keys

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.

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

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.

Do you know C++? The following may help you see the distinction...

  // x is a variable that records a set of values   set<int> x;

  // insert a value into x
  x.insert(5);

  // y is a variable that records a set of variables   set<int*> y;

  // insert a dynamic variable into y
  y.insert(new int(5)); Received on Thu May 28 2009 - 17:49:33 CEST