Re: RM and abstract syntax trees

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.

>> <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>
>>

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. Received on Tue Nov 13 2007 - 03:42:15 CET