Re: SQL (was: Why using "Group By")

From: Mikito Harakiri <mikharakiri_at_ywho.com>
Date: Thu, 13 Mar 2003 14:56:13 -0800
Message-ID: <Y58ca.24$wV5.164_at_news.oracle.com>


"Bob Badour" <bbadour_at_golden.net> wrote in message news:NY7ca.4$GY2.112751_at_mantis.golden.net...
> > In SQL there is a "select" clause, it corresponds to projection
operation
>
> Actually, it is a combination of extend, project and summarize.

Trivially so for "extend" being inverse to "project". Not sure about summarize. Summarize result extends the input relation with additional "aggregate" column, and projecting the input relation to the "group by" column at the same time. In the set symantics you have to say no more, but in the bug semantics I have to apply restriction to make rows "distinct".

> Table closure actually. Have you ever considered that SQL's cartesian
> product followed by restriction, if handled correctly, is a poor cousin of
a
> relational join? Have you ever noted that it forces the effort to identify
> the common columns onto the user?

Why is it such a big deal?

> > Subquery
> > into the "select" clause, as we saw, is a nice way to express
aggregation.
> > Chris Date considers scalar subqueries disgusting, but are they really?
>
> Implicit conversion from a table to a scalar? Yeah, I agree they are
> disgusting.

You wouldn't agree that any aggregate operation is a conversion of a table/collection to a single value?

> > Finally, a
> > subquery in the "where" clause allows us to express logical quantifiers.
> > This is as much SQL as I'm able to digest so far, but I wasn't
> disappointed.
>
> Without logical identity, the first question that comes to mind is:
Logical
> quantifiers of what exactly?

This idea needs more maturity, granted. Received on Thu Mar 13 2003 - 23:56:13 CET

Original text of this message