Re: Book Review: "SQL Tuning" by Dan Tow

From: Bob Badour <bbadour_at_golden.net>
Date: Fri, 2 Jan 2004 09:58:51 -0500
Message-ID: <ucWdnSR4PfXbGmiiRVn-sA@golden.net>

"Christopher Browne" <cbbrowne_at_acm.org> wrote in message news:bt2tru$2lubu$1_at_ID-125932.news.uni-berlin.de...
> Martha Stewart called it a Good Thing when "Bob Badour"
<bbadour_at_golden.net> wrote:
> >> you mean this book? Is it really any good? Looks like inter-database
stuff
> >> and that is always watered down.
> >>
> >>
> >

http://www.amazon.com/exec/obidos/tg/detail/-/1558607536/qid=1073013652//ref
> >> =sr_8_xs_ap_i2_xgl14/002-7457171-4222439?v=glance&s=books&n=507846
> >
> > Yes, that is the book in question. I do not know how you expect it
> > to be watered down. It has an excellent inventory of available
> > physical structures describing their impact on performance and takes
> > a principled approach to performance tuning.

>

> No doubt his gripe is that by not slavishly cleaving to one particular
> version of one particular vendor's database, the book cannot provide
> "cookbook" answers that work with that DB version and no other.

>

> I was quite favorably impressed by the book; the principles it
> suggests are ones likely to survive version upgrades, whereas those
> that learned the "20 rules of Oracle 5 optimization" had to restart
> their education when Oracle discovered the wonders of cost-based
> optimization.

I first encountered the principles in Shasha's and Bonnet's book in Shasha's 1992 version of the book, and I have successfully applied those principles in a quite variety of products and product versions. It's sort of like the difference between getting a fish and learning to fish.

As far as optimizing individual SQL statements, I have always found that doing so is quite simple. First, write the query such that the dbms does the work and then use the redundancy in the language to write several logically identical queries. Finally, pick the one that performs best and creates the fewest concurrency problems.

The Sybase derivatives are a little different. It amazes me that a decade after I first used Sybase, its "optimizer" still evaluates joins in the least efficient order. One generally has to force Sybase derivative dbmses to evaluate joins in a particular order by writing procedural code using temporary tables. Still, I start with a query that expresses the intent and then break that up. Received on Fri Jan 02 2004 - 08:58:51 CST