Re: RM and abstract syntax trees

"Ed Prochak" <edprochak_at_gmail.com> wrote in message news:1194897061.766079.124780_at_22g2000hsm.googlegroups.com...
> On Nov 9, 10:14 pm, Marshall <marshall.spi..._at_gmail.com> wrote:
> > On Nov 9, 4:34 pm, David BL <davi..._at_iinet.net.au> wrote:
> >
> >
> >
> >
> >
> > > On Nov 10, 5:29 am, Marshall <marshall.spi..._at_gmail.com> wrote:
> >
> > > > The issue is that pointers need referencing and dereferencing
> > > > operators which are not part of the relational algebra. Pointers
> > > > have an associated address space. Pointers are volatile and
> > > > anchored to a specific run of a specific program on a specific
> > > > machine, whereas relational ids are durable. Pointers are
> > > > physical and ids are logical.
> >
> > > You appear to draw conclusions from your assumption that the RDB is
> > > durable whereas the machine process is not. What happens if you
> > > delete the RDB? To what extent is a bank account identifier
> > > meaningful without the associated DB?
> >
> > > What about pointers between objects in a POS (Persistent Object
> > > Store)? Are you saying they aren't really pointers because the
> > > address space is durable?
> >
> > > I would rather say that the pointer concept is orthogonal to volatile
> > > versus durable concerns.
> >
> > You misunderstand me.
> >
> > I'll take you up on the object graph example. Suppose you
> > have an object graph on one machine, with edges encoded
> > as pointers. Suppose you serialize that object graph, send it
> > to another machine and deserialize it there. The pointer values
> > will all necessarily be different.
> >
> > Suppose you take the same graph as a pair of relations for
> > nodes and edges, with node ids. Now consider the
> > serialize/deserialize scenario again. The key values
> > are all the same.
> >
> > The point is, pointer values are transient, ephemeral,
> > temporary, living only as long as the *process* they
> > are embedded in. Whereas the key values in the
> > relations are a first class part of the data, and so
> > live as long as the data does.
> >
> > The point is not the lifespan of the data; the point
> > is the lifespan of the pointer values relative to the
> > lifespan of the data. With keys, it's the same; with
> > pointers, it's not.
> >
> > And this was only one of a number of differences
> > I cited. The two aren't the same.
> >
> > Marshall
>
> I see your point about persistence. I still contend there are more
> similarities than differences.
>
> I already gave an example of a dereference operation. Syntactically is
> is just a SQL SELECT statement, but semantically I claim it opereates
> just like a wordy dereference. The point is not whether Relational
> algebra has an explicit dereference operator. The point is can
> something be set up to operate like a pointer.

If your point is that pointers can be simulated inside a relational system, then I agree.
Where I disagreed with David BL was whether the data item (OID) that is used to stand for a pointer really is a pointer.

>
> <side note>
> The reason I make a fuss about this is the abuse of these surrogate
> keys in production applications. There are times when surrogates are
> necessary, but too often rather than doing real data modelling,
> developers slap on a surrogate, call it the primary key, and conclude
> their database is normalized.
> <end side note>
>

Agreed, strongly. Received on Mon Nov 12 2007 - 22:36:35 CET