Re: what are keys and surrogates?

JOG wrote:

>Why on earth can't people be identified inside the database by their
>name, and parent's name, if that works outside?

It doesn't. I thought we already agreed on that. It's the whole point of this example that it doesn't.

If you don't find the example convincing, you'll have to come up with something other than trying to bend it into something else.

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

If you don't find the example convincing, fine. If you choose not to understand it, fine. But stop trying to bend it into something else.

>So to deal with it in real life you might specify the Grandparent's
>name too. And if that were the same, then the Great-GrandParent as
>well. If that gives you the way to identify the person uniquely,
>excellent - you now know if you ever need to build a database for the
>info, you can use a table with a PK(Name, P, GP, GPP). If not, just
>keep on going with those ancestors.
>
>No OID's necessary.

Except that

1. there is no fixed limit on the length of the chain.
2. you'll end up with an awful lot of NULLs on those tables

>> >If that's not enough and you need
>> >grandparents to distinguish them, then use that too, and so on. Just
>> >work out how you identify something in real life and then use that in
>> >the database.
>>
>> Yes, that's exactly what I've been doing here.
>
>No, I meant if you use someone's ancestors to identify them in real
>life, then that's exactly what you should use to identify them in a
>tuple.

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. A strong requirement; sensible, too, at least for relational databases; and one this example doesn't meet.

Who said that the same person will always be identified by the same fixed path? WHo said that the paths for different persons will always be of the same length? I stated neither. It seems very unlikely.

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

> There are no OID's in the bible. And your
>example showed people being successfully referred to by their parent,
>grandparent, etc, so its absolutely clear we don't need anything else
>to identify them.

You're doing it again: confusing, in your wording, "parent" and "grandparent" with "the parent's name" and "the grandparent's name".

>In fact the example is a cracker - I can use it in the future not only
>to explain why we don't need OID's, but also to show that identifiers
>can get very long, and that's why we make up things like SSN's to make
>life easier.

Absolutely. Life in biblical times would have been much easier if every Joshua had worn a chip on his shoulder.

-- 
Reinier