Re: The Practical Benefits of the Relational Model

From: Nathan Allan <nathan_at_alphora.com>
Date: 3 Oct 2002 16:08:31 -0700
Message-ID: <fedf3d42.0210031508.38002a34_at_posting.google.com>


mikharakiri_at_yahoo.com (Mikito Harakiri) wrote in message news:<bdf69bdf.0210031023.375229d8_at_posting.google.com>...

Oooo. I guess I will bite on this one.

> What relational purity really buys us?

Practical benefits! (see my original posting)

> Unability to express
> aggregation?

Myth.

> Ignoring nulls?

Hardly ignored. Heartily addressed. I would twist your argument and state that SQL "ignores getting right answers." Let me pick on a SQL (non-relational) product for a minute. MySQL's arithmetic operators return null if there is an error/overflow. This means that if I have, say, a divide by zero error in a check constraint (assuming MySQL has those), my constraint will succeed! Problems like this wouldn't be an issue were it not for nulls. BTW, there _are_ good relational mechanisms to deal with the problems that nulls attempt to addresses.

> Not admiting nested subqueries?

"subqueries" only makes sense when referring to a calculus, which, is merely one way of formulating relational queries. Regardless, in this context the RM not only says that you can have "nested subqueries" but _must_ have them to be relationally complete.

> Total
> ignorance about domain operators?

I think you mean to aim this criticism toward pseudo relational products.

> God forbid nesting/unnesting!?

Fully allowed.

> Recursion impotence?

A common "SQL = Relational" blunder. The RM _requires_ recursion in order to be complete.

> It is often emphasized how beatuful relational theory is, because it
> is based on the set theory.

No, it is beautiful because it gives us the simplest, yet most powerful, model for data management. It's like "the mathematics of data." As illustrated by my original posting, implementing it results in many practical solutions to problems we commonly work around today.

> While there is undoubtedly some
> connections, but may I ask why set union is a basic relational
> operator, and intersection is not? (Intersection could be expressed
> via combination of join and projection).

The relational model certainly allows for a native intersection operator as an alternative to join/project or "where in".

Please be careful not to punish the RM for SQL's sake. ;-)

--
Nathan Allan
Received on Fri Oct 04 2002 - 01:08:31 CEST

Original text of this message