Re: Alternatives to SQL ...

On Fri, May 24, 2002 at 12:43:36PM -0500, Gunther Schadow wrote:
> - Sending a parse tree in XML for processing by the optimizer.
>    This circumvents the SQL language and avoids the kinds of
>    syntactic ideosyncrasies of SQL (e.g., where you put commas.)
>    This is fairly trivial, but of course the question is, would
>    it be worth it?

I don't know if you can design something in XML that is expressive and
simple enough to compete with SQL. SQL is a simple language, why replace it
with something unless it is demonstrably better.

> - Sending an execution plan in XML directly to the executor.
>    This now circumvents the SQL parser and optimizer. I know this
>    in in a way against the relational doxology and I don't take that
>    light-heartedly. However, isn't it true that most optimizers
>    cannot deal very well with more than 6 joins? I may be wrong,
>    but I find myself spending quite a bit of time fighting with the
>    Oracle or PostgreSQL optimizer to convince it to choose the plan
>    that I want. There is so much magic to it with hints and the
>    way you write SQL (where in relational theory the expressions are
>    equivalent, they make huge difference in what plan is being
>    generated.) So, it appears to me almost easier to just send a
>    plan directly and have the system execute that plan.

The detail contained in plans is quite substantial (as you can see using
EXPLAIN VERBOSE). I doubt you can rely on programmers getting all the
details right. As for the join problem, some people get good results tweaking
the genetic query optimiser using documented interfaces. And if you don't
like the way the tables are joined, the INNER/OUTER/LEFT/RIGHT JOIN syntax
in SQL allows you to force the order.
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> There are 10 kinds of people in the world, those that can do binary
> arithmetic and those that can't.