Re: RM and abstract syntax trees
Date: Tue, 13 Nov 2007 12:26:39 GMT
Message-ID: <3Kg_i.3569$ET.2641_at_trndny03>
"paul c" <toledobythesea_at_ooyah.ac> wrote in message
news:ba8_i.205644$th2.103703_at_pd7urf3no...
> David Cressey wrote:
> ...
> >> 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.
> >
> >
>
> I think the very idea of comparing pointers to relational constructs is
> unfortunate and mis-represents relational ideas, no matter whether one
> thinks of pointers in the more general way Bob B does or the
> machine-traditional way David C and I do. When we have join and project
> at the logical level, talk about "de-referencing" is irrelevant to a
> data design.
>
> Pointers of either kind are nothing more than implementation devices
> when it comes to the RM. I'm even getting the impression that some
> people think a data design that involves surrogate attributes must
> involve pointers. This seems to imply that those are the only kind of
> attributes that could do that whereas I would say that as far as the RM
> is concerned, no attributes are ever equivalent to pointers. If one is
> using a dbms that has a feature to generate keys, I don't see why one
> would take that to be a relational feature, don't see why a logical data
> design needs pointers in the first place, don't see what surrogates have
> to do with the RM, don't see what lazy instant gratification has to do
> with logical data design, blah, blah, blah.
>
This is a good comment to close the subthread about pointers.
Now maybe we can get back to RM and abstract syntax trees, the main topic
of discussion.
Is there anything about syntax parsing that makes the RM an awkward tool for
modeling it?
Received on Tue Nov 13 2007 - 13:26:39 CET