Re: what are keys and surrogates?

From: JOG <jog_at_cs.nott.ac.uk>
Date: Sun, 17 Feb 2008 16:55:20 -0800 (PST)
Message-ID: <0fb09b9d-355a-4e1e-9281-737385babc75_at_u72g2000hsf.googlegroups.com>


On Feb 17, 11:16 pm, rp..._at_pcwin518.campus.tue.nl (rpost) wrote:
> 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.

  1. You have an example of someone who can only be identified by their lineage.
  2. I respond by saying fine, then use lineage to identify them in the database.
  3. You say you can't, because it doesn't work in the real world.....even though your example was of lineage being the only thing that you could use in the real world.

Doesn't that seem just a little bit of a weird argument?

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

It shows no such thing (still baffled why you think it does, dude). 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.

Do you think there's a difference between attributes and relationships that is anything but arbitrary?

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

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?

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

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

I think you're misrepesenting (misunderstanding?) my point of view, because I'm not saying that.

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

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

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

Well given there are only values our here in the real world, I thought it would be obvious I was talking about their names, given that's what your example is about.

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'? I like not to think about it meself. Bhuddism has the notion as a central tenet, and while I know they're probably right, it always suprises me they are so chilled about it all and not running around panicking. I always find OID's to be a related topic...

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

Amen to that. Regards, J.

>
> --
> Reinier
Received on Mon Feb 18 2008 - 01:55:20 CET

Original text of this message