Re: relations aren't types?

"Bob Badour" <bbadour_at_golden.net> wrote in message news:DuGdncCm4O1a3Xui4p2dnA_at_golden.net...
>
> >
> > I have to agree. I don't see any logical difference between a row
> > in a relation and an object. (Alternatively, between a relation
> > heading type and a class.)
>
> One has transparent structure and generic operations while the other has
> opaque structure and specific operations. You really see no logical
> difference? The differences glare at me.

I see no *logical* difference between transparent structure and opaque structure. That's an implementation detail. Or, another way to look at it: "no user-visible components" is just a nullological issue. It's just a special case of having a nonnegative number of visible components.

As far as generic operations vs. specific operations, I see no reason to deny generic operations to scalars nor specific operations to tuples.

> If there is no difference between a tuple and a type, what difference exists
> between an n-ary relation and a unary relation?

What indeed? What need is there for such a difference?

Simple example: a Point relation with int x, int y columns vs. a unary relation on a tuple-type with attributes int x, int y. What's the logical difference? Why should there be operations that are allowed on one but not on the other? What value would such a restriction provide?

> > Well, maybe one thing. OOPLs are heavily into use of pointers or
> > references, and these don't work well with relational data management.
> > But that's not a showstopper in my book. It seems eminently possible
> > to design a data-management OO (or "OO-like") PL that didn't have
> > pointers or references, but leaned heavily on relations instead.
>
> I agree. It's called the relational model, and you can find a suggested
> language template in _TTM_.

We agree then.

But certainly relation-oriented languages occupy a very broad design space.

Marshall Received on Mon Dec 22 2003 - 18:35:34 CET