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 *?  ;-)

I can not agree with that.

First a frame of reference.
Supporting levels, low to high:
(fatic -) syntactic - semantic - pragmatic.

Numerical vs. symbolic identification of attributes has consequences (i.e. differs at the pragmatic level.) Names rely on the existance of common semantics, numbers on form agreement (isomorphism)
(Both only implied in practise most of the time, but hey! this is cd/t/ :-)

This choice goes well beyond syntax.

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

Intuitively: Yep, I think it can't either. My guess: demarcating this loss will take some effort and time, though.

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

That is where semantics and the (human) ease of names kick in.

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

I wish I had some nice words to encourage you to share those problems. Received on Sat Apr 08 2006 - 02:59:46 CEST