Re: Natural keys vs Aritficial Keys

On May 29, 1:05 am, "Walter Mitty" <wami..._at_verizon.net> wrote:
> "David BL" <davi..._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?

Trying to persuading others can be as simple as suggesting they read the relevant literature. If they have already but still have a different opinion or they're ignorant and want to remain so then there's no point worrying about it.

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

Yes that's correct. There was a misunderstanding. When you originally said:

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

I read it like this:

    > Incidentally, I think I understand just a little bit about the     > difference between a variable that a) records a set of values and

    > b) records a set of variables.

Can you explain why you want to compare [a variable that records a set of values] to [a set of variables]? It doesn't seem to reflect the actual situation under discussion. Received on Fri May 29 2009 - 03:29:32 CEST