Re: Constraints and Functional Dependencies
Date: Thu, 01 Mar 2007 13:56:52 GMT
Message-ID: <EYAFh.2878$PV3.38623_at_ursa-nb00s0.nbnet.nb.ca>
Marshall wrote:
> On Feb 27, 9:26 am, "Tony D" <tonyisyour..._at_netscape.net> wrote:
>
>>On Feb 27, 3:35 pm, "Marshall" <marshall.spi..._at_gmail.com> wrote: >> >>>You didn't ask me, but I can tell you what *I* like about SQL: >> >>>select, project, extend, union, aggregate, and especially join! Join >>>is awesome. >> >>>Oh, and constraints. >> >>>Marshall >> >>For a first attempt, SQL was ok, I guess. Who knows what might have >>happened if QUEL had been presented to the standards committee as a >>serious alternative to SQL though ... (Ingres users can, of course, >>try it and find out for themselves ;)
>
> Do you have any references for QUEL for someone who would like
> to read about the language? If one is interested in learning about
> functional languages, or OO languages, one has many to choose
> from, and can see many different approaches being tried, and
> compare features, etc. For relational languages, there is SQL,
> and not a lot else. Setl or Nestl? Not altogether algebraic.
> There's TutD, of course. I am impressed with its semantics,
> but I can't say I find it compelling. Its relational features are
> of course very advanced but outside of that it's quite staid.
> My aspiration is for the advanced relational semantics of
> TutD combined with some of the goodness of modern
> functional languages. My expectation, Tony, is that you
> would be sympathetic for the desire for higher order
> functions. :-)
>
> In any event, I expect I would enjoy reading about QUEL.
Perhaps not what you expected, but I remember an anecdote Fabian shared with me several times:
In the late 80's or early 90's, Fabian wrote a magazine article on the topics of language redundancy and the problems of ignoring relational principles. He took an empirical approach by thinking up a half-dozen or so ways to write the same query and measured the response on a variety of products.
While his experiment peripherally measured the effectiveness of various optimizers, it was not a benchmark, and he made it very clear he was not benchmarking products. Instead, his experiment demonstrated the pitfalls of having too many ways to say the same thing and the dire consequences of flouting theory.
What Fabian found was a lack of consistency. The same vendor across differing formulations of the query gave differing results. The exact same query across different vendors gave differing results. Duplicates in the source tables yielded wildly differing cardinalities in the results, and even when cardinalities were the same, performance ranged over many orders of magnitude.
For example, the vendor that had the fastest performance also had one of the slowest if not the slowest for another formulation of the same query.
By now, you are probably asking: "What does this have to do with QUEL?"
At the time Ingres did not have a native SQL engine but a native QUEL engine. For SQL, it used a translator, which if I recall correctly was designed by Chris Date.
Consequently, Ingres was the only product that offered reasonably consistent results. None of the Ingres formulations of the query necessarily gave the absolute best performance, which one can only expect given the extra translation step, but all of them gave good performance. In other words, Ingres was the only vendor that didn't punish users for failing to achieve expert level skills before using the product.
Consider the relative cost of hiring someone who can write a correct query versus the cost of hiring someone who can write a correct query that performs best on a given dbms. Consider the relative cost of hiring someone who can write performant queries on a variety of dbmses.
Sadly, I believe Ingres abandoned their native QUEL engine for a native SQL engine--probably to compete on benchmarks.
I heard this anecdote so many times because of another vendor. I used to do a lot of work with Gupta's products. In spite of the "This is not a benchmark" disclaimers plastered all over the article, someone at Gupta wrote the magazine to complain about not receiving advance notice of the benchmark and not being invited to participate so they could tune the queries and their product.
Some folks are just too stupid for words. Received on Thu Mar 01 2007 - 14:56:52 CET