Hello,

I'm contemplating writing an Sql parser, more so for my own personal
education, and am wondering if anyone has had any experience that they can
share with me on a question that I have.

I have good experience with Sql, since I maintain and develop my companys Sql
database engine. The product I maintain parses Sql and constructs a parse tree
based on the elements of the Sql statement. Would building the tree using
"Relational Algebra" elements be better instead? The Sql statement would
be strictly Dml.

Some advantages that I can think of:

1. Insulates the core logic of the query processor from the query language
2. Provides identical semantics to redundant elements of the query
language


- Danny

"Danny deSousa" <Danny_deSousa (AT) telus (DOT) net> wrote

The latter advantage is particularly important for usability. Years ago,
Fabian Pascal did a comparison of different SQL dbms's ability to provide
good, consistent performance for logically equivalent queries using
different redundant elements of SQL. If I recall correctly, the dbms that
could achieve the fastest performance would also deliver the worst
performance depending on how the user expressed the query. Ingres delivered
the most consistent performance because, at the time, it supported SQL by
translating it to QUEL.

Fabian mentions QUEL's advantages without rehashing his earlier essay at
http://www.pgro.uk7.net/x_terminology.htm

"Bob Badour" <bbadour (AT) golden (DOT) net> wrote

[snip]
I am never one to downplay Ingres' manifold virtues, but let me point out
that the last statement above stopped being true more than a decade ago.

Ingres only briefly translated SQL into QUEL. That was the approach taken
in the later versions of Release 5, which came out in the late eighties.
Since Release 6, and onwards, Ingres processes SQL directly (although QUEL
is still fully supported).

Ingres still does an excellent job of translating SQL queries into a
canonical form that leads to the same (optimal) plan. So much so that in
our Advanced High-Performance Ingres programming course we tell students
that if they find two logically equivalent, unambiguous queries, that lead
to different query plans, then that is by definition an Ingres bug. The
corollary to that is that when we teach query tuning, we tell the students
that it is (practically) futile to attempt to re-write the query. If it
correctly described the required data in the first place, then all
equivalent formulations should lead to the same (optimal) plan. There are
some trivial exceptions to this general rule, but for most purposes it is a
true statement.

Bob's statement is not entirely incorrect though. The Ingres engine does
include logic that was originally there to support QUEL, and the parser and
the optimizer can both exploit it when processing SQL, but there is no
intermediate translation to QUEL code. It works more like the original
poster suggested he wanted to do things.

Roy Hann (rhann at rationalcommerce dot com)
Rational Commerce Ltd.
www.rationalcommerce.com
"Ingres development, tuning, and training experts"

"Roy Hann" <rhann (AT) globalnet (DOT) co.uk> wrote

As I said, Fabian wrote the essay years ago.


I had heard that Ingres foolishly gave up this advantage.


<snip>

My statement was not incorrect in any way, shape or form. Fabian wrote the
essay when I said he wrote the essay, and, at the time, Ingres achieved its
consistent performance by translating SQL to QUEL.

The point in my earlier post was not about Ingres but was an answer to a
question regarding the advantages of translating SQL to a direct
representation of the relational algebra. There are, of course, many
advantages to doing so, and the person asking the question hit upon a major
advantage for which published empirical evidence has existed for well over a
decade.

"Bob Badour" <bbadour (AT) golden (DOT) net> wrote

<snip>
True enough. In my eagerness I expressed myself very carelessly. Please
forgive me.

I was eager to highlight the fact that Ingres only ever briefly translated
SQL to QUEL and that this was represented as a "lack of native SQL support",
which was a devastating marketing tool in the hands of the vendors of
competing products. While your purpose in recalling it seems to have been
positive, the technique of translating SQL to QUEL proved very negative for
Ingres in the marketplace. The taint lingered for many years, and for all I
know it continues to linger. It is a touchy subject amongst those of use
who think that Ingres has been very badly treated over the years.

So I gathered. And the point in my post was to emphasize that Ingres no
longer works the way described and alluded to. I don't think that has any
bearing on your point one way or the other. It is simply an update on the
current state of play for anyone who might be interested.

Once again, I do apologize for my sloppiness.

Roy Hann (rhann at rationalcommerce dot com)
Rational Commerce Ltd.
www.rationalcommerce.com
"Ingres development, tuning, and training experts"

"Bob Badour" <bbadour (AT) golden (DOT) net> writes:

The pros and cons of SQL vs. quel are strictly in terms of human factors of
expressing queries. Many people preferred QUEL because it was just
syntactic sugar for tuple relational calculus, a well defined paradigm.
SQL is a kidn of hybrid of different paradigms, and as such can be less
intuitive or semantically clear without looking at the actual language
reference to understand the behavior of certain constructs. At one time,
Ingres offered more consistent performance, independent of how the user
expressed a query, because it had a cost-based optimizer that chose a plan
with estimated cost that was optimal in the set of all plans considered by
the optimizer (which is a strict subset of the set of all possible plans).
Most notably Oracle for many years had only heuristic based optimization
and the performance of SQL queries was dependent on the order in which
relations were listed in the FROM clause, which dictated join orders
in the query plan.

Joseph

<Joseph>; <joseph (AT) aracnet (DOT) com> wrote

With all due respect, you are ignoring the fact that Quel is a less
redundant language and how this impacts performance optimization.

"Bob Badour" <bbadour (AT) golden (DOT) net> writes:


which just means that the optimizer is a bit harder to implement in
SQL. Note that many (though surely not all) of the redundant features
in SQL were created to extend the power of SQL beyond relational calculus
(and thus beyond QUEL). SQL optimizers today handle correlated nested
queries that can be unwrapped into joins just fine, for example. I don't find
SQL particularly intuitive, though.

Cheers,

joseph