Re: relations aren't types?

From: Bob Badour <bbadour_at_golden.net>
Date: Sun, 21 Dec 2003 19:54:14 -0500
Message-ID: <DuGdncCm4O1a3Xui4p2dnA_at_golden.net>


"Marshall Spight" <mspight_at_dnai.com> wrote in message news:kSnFb.172699$_M.781016_at_attbi_s54...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
news:bs38nn$oqm$1_at_news.netins.net...
> >
> > I have read and re-read Date & Darwin's rationale for using classes to
> > define types that are domains of attributes in a relation. I completely
> > agree that is an appropriate use of a class. But the reasons for not
using
> > a class to define a type that is either a relation (or, my preference --
a
> > function) or an element of the same are not at all satisfying. That is,
> > I've read the rationale and I don't buy it.
>
> 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 too have read and reread the appendix
> in TTM on "the first great blunder" but I don't see anything blunderous
> about it.

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

> 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_. Received on Mon Dec 22 2003 - 01:54:14 CET

Original text of this message