Re: double linked list

From: DA Morgan <>
Date: Sun, 02 Feb 2003 17:59:58 -0800
Message-ID: <>

--CELKO-- wrote:

> >> Looks like we won't see a "connect-by" chapter in your book;-) <<
> I do mention it -- as the work of Satan :)
> >> I would mention that there is a striking syntactic and semantic
> similarity between "connect-by" and "group-by"... <<
> Syntax, maybe if you count using the word "BY" in the construct. But
> they are nothing alike.
> Here is how a SELECT works in SQL ... at least in theory. Real
> products will optimize things when they can.
> a) Start in the FROM clause and build a working table from all of the
> joins, unions, intersections, and whatever other table constructors
> are there. The table expression> AS <correlation name> option allows
> you give a name to this working table which you then have to use for
> the rest of the containing query.
> b) Go to the WHERE clause and remove rows that do not pass criteria;
> that is, that do not test to TRUE (reject UNKNOWN and FALSE). The
> WHERE clause is applied to the working in the FROM clause.
> c) Go to the optional GROUP BY clause, make groups and reduce each
> group to a single row, replacing the original working table with the
> new grouped table. The rows of a grouped table must be group
> characteristics: (1) a grouping column (2) a statistic about the group
> (i.e. aggregate functions) (3) a function or (4) an expression made up
> of the those three items.
> d) Go to the optional HAVING clause and apply it against the grouped
> working table; if there was no GROUP BY clause, treat the entire table
> as one group.
> e) Go to the SELECT clause and construct the expressions in the list.
> This means that the scalar subqueries, function calls and expressions
> in the SELECT are done after all the other clauses are done. The AS
> operator can give a name to expressions in the SELECT list, too.
> These new names come into existence all at once, but after the WHERE
> clause, GROUP BY clause and HAVING clause has been executed; you
> cannot use them in the SELECT list or the WHERE clause for that
> reason.
> If there is a SELECT DISTINCT, then redundant duplicate rows are
> removed. For purposes of defining a duplicate row, NULLs are treated
> as matching (just like in the GROUP BY).
> f) Nested query expressions follow the usual scoping rules you would
> expect from a block structured language like C, Pascal, Algol, etc.
> Namely, the innermost queries can reference columns and tables in the
> queries in which they are contained.
> The CONNECT BY is a rule for a cursor to traverse a chain.

So because you don't happen to like something it makes the product 'horrible'? Not ... there are certain features or facilities in the product I don't use and why ... just a blanket thumb down? I'm not impressed. I can come up with a list of poor features and poorly implemented features in any product from assembly language on up. Does that mean we should we go back to 3x5 cards?

When you are ready to demonstrate a superior implementation in another SQL RDBMS please let us know. And I don't mean superior in terms of some theoretical concept like building a database in fifth normal form. I mean superior in terms of performance and scalability in the real world.

Daniel Morgan Received on Mon Feb 03 2003 - 02:59:58 CET

Original text of this message