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

Marshall Spight wrote:
> dawn wrote:
> >
> > Are you suggesting there really is some valid
> > reason for insisting that there be no function mapping a subset of the
> > natural numbers to attribute values? I can imagine someone concerned
> > about maintaining that ordering or some such, but if that is done by
> > the dbms software, who cares? How bad would it be if you got
> > attributes in the exact same order each time you did a select *? ;-)
>
> 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?

We could surely define an order then, but I see your point in this regard. Similarly if you do a union or look at equality. Each of these could ignore the ordering, but if the ordering were required, it would have to come up with something for the result.

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

Since I'm not starting with theory but with an actual example, that example performs joins, for example while ignoring ordering. When performing any set operations (with SQL) the order is unused data. When performing typical reads and writes, however (not with SQL), the order is what is used and the attribute names are just synonyms for the number of the attribute.

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

OK, I'll think about that. Of course it _works_ for a dbms to retain such ordering (examples are numerous), but it is not then an RDBMS. If you don't work with set operations, but with graph navigation, do you still have these issues? I recall an odd situation where I had to reorder attributes to do a union. That is the only time I can recall wishing the attributes were not ordered. It didn't bother me when working with SQL since the ordering was then ignored.

This is a seemingly tiny detail, of course, but it comes up more often than one might guess in the RM literature as if it were problematic and it just doesn't seem to be in practice. I'll grant I'm not working with a strictly RDBMS product (but who is?) --dawn Received on Fri Apr 07 2006 - 04:57:18 CEST