Re: RM and abstract syntax trees

On Oct 31, 11:59 pm, Marshall <marshall.spi..._at_gmail.com> wrote:
> On Oct 31, 8:31 pm, Jonathan Leffler <jleff..._at_earthlink.net> wrote:
>
>
>
>
>
> > Marshall wrote:
> > > On Oct 31, 7:50 pm, David BL <davi..._at_iinet.net.au> wrote:
> > >> Isn't it helpful to see the analogy with a pointer dereference?
>
> > >> I'll leave it up to you as to whether you dislike the analogy between
> > >> node identifiers and pointer values, and the idea that a join can be
> > >> compared to a pointer dereference. Perhaps you are right and the
> > >> analogy creates confusion.
>
> > > I think if we are clear about it being an analogy we are on solid
> > > ground. But as soon as we start thinking pointers and references
> > > are the *same* thing we are in trouble, because now we can't
> > > see the differences anymore.
>
> > > I think Date actually nails this issue. He says (roughly) that
> > > pointers add complexity but don't add any expressive power.
>
> > Isn't the other 'point' that 'pointers point somewhere' but values
> > stored in a relation don't - that relational database bases work on
> > associative addressing. In particular, even in a foreign key, the value
> > doesn't point to the referenced primary key; it merely contains the same
> > value as some entry in the referenced table. It may also contain the
> > same value as a large number of other places in the database.
>
> Yes, well put.
>
> I mentioned previously that pointers are only meaningful or
> functional within the context of a specific, typically non-portable
> address space. Without the address space, pointers might as
> well be random numbers. So if you are going to pack up some
> data and move it from, say, one machine to another, you
> have to go through all sorts of contortions to preserve some
> semblance of pointer semantics. And as anyone who's dug
> through the code for Java serialization, this is quite ugly
> and error prone. Whereas if you want to copy some
> relations from one place to another no transformations of
> any kind are necessary. Which rather highlights how the
> relational form is a logical form, and not a physical form.
>
> Marshall

I think the pointers being discussed are the arbitrary surogate keys.

IOW consider these two tables

tabA
keyA INT PK
value anything

tabB
keyB INT
valB INT FK to tabA

the values loaded in keyB can be extracted from the original database and loaded into another database without damaging the relations. I see these values as pointers. Granted they are in a virtual address space where the DBMS acts as a memory management unit to fetch data from the physical location.

I think you are referring to these DB pointers being the values returned from some pseudocolumn ROWID available in some DBMS products. These can be considered pointers too, but not as easily as the surrogate key values are. Needless to say, I think this is more than just an analogy (between surrogate key values and pointers).

I did see others addressed this issue (soory I'm coming in on this late), but not to the extent of identifying the address space as virtual. With caching and swapping, program data can live in multiple physical memory locations. RM data could move between databases in an analogous manner.

Ed Received on Fri Nov 09 2007 - 21:12:20 CET