Re: Just for the record

"Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message news:UtApg.4730$pu3.110289_at_ursa-nb00s0.nbnet.nb.ca...
> David Cressey wrote:
> > <kvnkrkptrck_at_gmail.com> wrote in message
> > news:1151522748.914377.59710_at_d56g2000cwd.googlegroups.com...
> >
> >>Dijkstra: SOC = When solving a complex problem, focus on one aspect of
> >>the problem (correctness, efficiency, etc.) while bearing in mind that
> >>the other aspects exist.
> >
> > I really like this!
> >
> > I hope you won't mind if add a tangential comment.
> >
> > Many of the disastrous database designs that I've seen in the SQL world
stem
> > from a premature preoccupation with efficiency, at the expense of
> > sufficient attention to either relevance or correctness.
> >
> > This is particularly true when it comes to database design, but it's
also
> > truw about query design.
> >
> > A number of times, people have come to me with a SELECT that they want
> > speeded up. While playing with the query, I happen to notice that
SELECT
> > can give wrong answers, where SELECT DISTINCT will give right answers.
> > When I point this out to my consultee, he says, "yes but that's even
> > slower!" To me, this is putting the cart before the horse.
> >
> > To me, tuning a query is selecting a fast query among all the correct
> > queries.
>
> In a better world, this would be the role of the optimizer.

Strongly Agreed!

This reflects my history quite a bit. In 1994, I had been working with DEC Rdb/VMS for about ten years, and with Oracle for about 3 months. At that time, the RDB/VMS optimizer was better, by orders of magnitude than the Oracle optimizer.

Because I had been involved in teach Rdb/VMS I had had to learn a certain amount about the optimizer. But, in practice, the value to me of the optimizer was precisely in the fact that you could get very good results out of it while knowing very little about its internal workings. That's a smart optimizer.

So to me, in that context, Rdb/VMS was "a better world". There are some other ways in which Oracle was superior to Rdb/VMS. And in october of that year, Rdb/VMS was acquired by Oracle Corp.

>
>
> If a query is known to be incorrect, that disqualifies it.
> >
> > However, and this is somewhat new to me, is the idea of bearing in
mind
> > that all the other aspects exist. I like database design to be simple
and
> > sound, especially at the early stages. But even at the early stages,
there
> > is some sense that the final result is going to have to perform up to
some
> > required level.
>
> I suggest that 'bearing in mind' is perhaps misleading. A better phrase
> might be 'acknowledging'. Separating concerns means dealing with a
> concern to the exclusion of all other concerns while still acknowledging
> the importance of those other concerns.
>

It might be better. Let me think about that.

> Performance tuning might then be the process of addressing efficiency
> through symbolic transformation among equivalent correct queries to
> create a fast one from a clear one.

Agreed. And, in my experience, across a broad range of computation arenas, the "clear and correct" solution is also "fast enough for our pursposes" about three quarters of the time. That means you can put your tuning effort where it matters, rather than where it doesn't. Received on Sun Jul 02 2006 - 15:44:08 CEST