Re: dbdebunk 'Quote of Week' comment

David Cressey wrote:
> "Marshall Spight" <marshall.spight_at_gmail.com> wrote in message
> news:1125074070.799079.80320_at_z14g2000cwz.googlegroups.com...
> > x wrote:
> > >
> > > This means that there must be a one to one mapping between the generated
> key
> > > and some key with a meaning for the end user. Therefore that meaningless
> > > primary key is a pointer. But one of the goals of the relational model
> is to
> > > eliminate pointers from the data model.
> >
> > I'm not sure I share this point of view. I propose that
> > every pointer is meaningless; every key is meaningful,
> > whether system generated or not. The meaning is exactly
> > that it is the identity of the row. A randomly-generated
> > customer id still means something.
> >
> I'm not sure I share YOUR point of view, either. I would suggest that the
> key is not the identity of the row, but the identity
> of the entity described in the row. If we were to delete the row, and then
> insert another row with a different key, who is to say that the system
> didn't reuse the unused row?

I use the term "row" as a logical term, not a physical one.

> > Another difference between keys and pointers is that
> > keys are content-addressible, while pointers are
> > location-addressible.
>
> And the important thing, as far as I'm concerned, is that rows are
> "unpinned" in the RM.

Yes.

> In practice, this is only partly true. If the DBMS alters either the
> content or the location of a row, it may have to do some index maintenance
> to reflect that change. But at least a row is unpinned except for the pins
> in the index.

I think I'd just change this a tiny bit to say "In the implementation, this is only partly true."

Marshall Received on Sat Aug 27 2005 - 00:24:37 CEST