Re: Why is "group by" obligatory in SQL?

From: Cimode <cimode_at_hotmail.com>
Date: Fri, 24 Jul 2009 02:06:06 -0700 (PDT)
Message-ID: <64fabdc8-75c1-4505-a3a4-dec25c059997_at_k19g2000yqn.googlegroups.com>


Snipped.
> Who can know how the original designers arrived at their decision?
Probably because they believed in the myth of natural programming languages. SQL is no exception.

Dijskra clearly described the fundamental problem below...

The virtue of formal texts is that their manipulations, in order to be legitimate, need to satisfy only a few simple rules; they are, when you come to think of it, an amazingly effective tool for ruling out all sorts of nonsense that, when we use our native tongues, are almost impossible to avoid.

(http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667.html)

> There were certainly other languages from the early SQL era (such as
> QUEL) that would allow a similar formulation to what you propose,
> meaning what you intend.  (And indeed QUEL would allow other sensible
> things with aggregates that SQL still doesn't easily allow.)
>
> Personally I imagine the logic of SQL aggregation got defined in haste,
> was "good enough", and they just moved swiftly on to the next challenge.
> A small team, internal IBM rivalries, publication demands, etc. finished
> the job.
When looking at the grammar of the initial BS12, it seems obvious that we slowly shifted from a declarative oriented language to a verbose driven language.

In BS12 the expresssion of aggregation was by the assignment of variables seprating the aggregates from the operation such as

T1 = SUMMARY(EMP, GROUP(DEPTNUM), EMPS=COUNT, SALSUM=SUM(SALARY))
T2 = JOIN(T1, DEPT)
T3 = SELECT(T2, SALSUM > BUDGET)

comparing with SQL

SELECT d.Deptnum, Count(*) as Emps,

   Sum(e.Salary) as Salsum, Budget
 FROM Emp as e
 JOIN Dept as d ON e.Deptnum = d.Deptnum  GROUP BY d.Deptnum, Budget
 HAVING Sum(e.Salary) > Budget

It is reasonnable to assume that the BS12 approach consisting of differentiating operations and presentation, while more abrupt, forced the programmer to understand better the underlying concepts. In other words, the introduction of *aesthetics* is one of the factors that killed SQL's chances to ever become a relational operation language. Received on Fri Jul 24 2009 - 11:06:06 CEST

Original text of this message