Re: RM and abstract syntax trees

From: Ed Prochak <>
Date: Mon, 12 Nov 2007 19:51:01 -0000
Message-ID: <>

On Nov 9, 10:14 pm, Marshall <> wrote:
> On Nov 9, 4:34 pm, David BL <> wrote:
> > On Nov 10, 5:29 am, Marshall <> 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.

<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>
Received on Mon Nov 12 2007 - 20:51:01 CET

Original text of this message