Re: what are keys and surrogates?

From: rpost <rpost_at_pcwin518.campus.tue.nl>
Date: Mon, 18 Feb 2008 20:28:32 +0100
Message-ID: <e7f53$47b9dc60$839b4533$25132_at_news1.tudelft.nl>


JOG wrote:

[...]

As to the first part, we agree; I just misread what you wrote. Sorry.

>> >If you are saying that
>> >its because two people may have the same name and the same
>> >Parent_name, of course yes that would break things, but it would /
>> >equally/ stump you in real life too.
>>
>> And in real life, this is sometimes resolved by using chains of names,
>> *as the example shows*. Which, in turn, shows that the people involve
>> work with an underlying data model that contains person references.
>> That is the whole point of the example.
>
>It shows no such thing (still baffled why you think it does, dude).

You may be right: what I've said about this example thus far doesn't show it. It becomes clearer when someone's name changes (say, Jacob to Israel). In your "name paths" representation, name changes can still be expressed, but they become a lot more cumbersome.

>All it just shows that people can be identified by the "names" of
>their ancestors, which we've seen can happily be viewed as just more
>attribute values.

[...]

>> Except that
>>
>> 1) there is no fixed limit on the length of the chain.
>
>If you mean that the number of ancestors you need to specify to
>identify someone varies from person to person. well, yup, that would
>no doubt be correct. I don't see any problem there to identification
>and FOL. Is that an issue you have with RM or content based
>addressing?

The issue is the fixed arity of relations in the standard RM. We can't fix a schema, or we'll have to recognize name lists as 'atomic'.

>> 2) you'll end up with an awful lot of NULLs on those tables
>
>Don't necessarily disagree with that either, but thats an RM specific
>issue. In fact, when we agree we don't /need/ OID's for
>identification, and no doubt go on to talk about whether there are
>practical reasons why they might be useful, that'd probably come up.

Hmm, I like that idea. But I'm not 100% sold on the idea that name lists do suffice.

[...]

>> No, you're asking for something much stronger: that we have a fixed-format
>> formula for identifying any person, and that the same person is always
>> identified with the same parameters to that formula.
>
>I think you're misrepesenting (misunderstanding?) my point of view,
>because I'm not saying that.

OK, I didn't think you'd take this name list representation seriously.

[...]

>I never said you should identify /all/ people that way. I can maybe
>understand why you'd think that, because it might seem like i'm
>championing RM tables, but I'm not. All I am promoting is the logic of
>using /content-based addressing/. It's what we use in the outside
>world and should be a central component of any future 'ultimate data
>model (TM)'. Hey, maybe you'll even invent it once we get this OID
>stuff out your system? ;P

If by"content-based addressing" you mean OIDs must not occur in schemas, we still disagree. If you mean OIDs must not occur in queries, we've always agreed on that.

>> >I'm baffled why you'd think you'd corresponded to real life at all by
>> >inventing invisible numbers.
>>
>> They are *not* numbers. And OIDs are just a way to implement references
>> in terms of a flat relational model. Conceptually, what we have is tuple
>> references.
>
>Like CODASYL you mean? (I reinvented the network model a while back
>too. Feels a bit silly now).

I don't think so.

From what I read about it, the network model differs from OODB or E/R (as I know it) in two crucial respects:

  + no declarative querying, just precedural traversal (augh)   + logical representation is physical representation (augh)

[...]

>Interesting parallel question - would it scare you if 'you' were only
>made up of values and had no magic OID number acting as a substrate,
>no essential bit that was 'you'?

OIDs don't denote essence; they're just a trick to express equality of reference. There's no magic in how they refer or what they refer to.

-- 
Reinier
Received on Mon Feb 18 2008 - 20:28:32 CET

Original text of this message