Re: Interesting article: In the Beginning: An RDBMS history

dawn wrote:

>

The choice between a numerical vs. symbolic identification of attributes
is purely syntactic. One or the other, they have the exactly same computational power, although they require substantially different syntax to express the same things.

But wanting to have both at the same time, while it seems innocuous enough, actually leads to the loss of important algebraic properties. It seems like it can be reconciled, but I am convinced it can't, at least not without some loss.

(This is not to say that you can't have some *separate* numeric-to- name mapping, or multiple such, and use one in one context and another in another; there's nothing wrong with that. The problem comes in trying to have the mapping be part of the value, or part of the type.)

For example, if one has some relations R[a,b] and S[b,c], (here, use of [] indicates the attributes are ordered) and one does a natural join, what shall be the order of the resulting columns? If the proposal is R join S has columns, in order, [a,b,c], then that means that S join R would have column [c,b,a], which would mean that natural join would no longer be commutative. You can try to escape by proposing that the order of the columns not be relevant in determining equality, but then that breaks substitutibility.

I'm too tired to write up the substitutibility problem right now. I'll just mention that I spent long time trying to devise a syntax and semantics that would hold all the design value of named attributes with all the notational convenience of positional attributes, and I couldn't make it work. The problems are subtle, but pernicious.

Marshall Received on Fri Apr 07 2006 - 04:22:58 CEST