RE: SQL vs. traditional I/O?

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: DeLong, Eric
> 
> Joe, for this, you might want to review the QAQQINI configuration for
the
> options that allow DB2 to process tasks in parallel.  There are also
> optimization parms that might affect the performance of the SQL.

My problem with this is that I don't have the time to become an SQL
expert and, unlike native I/O, there's really a LOT of black magic with
SQL.  That's the nature of the beast.  With SQL, you simply tell it what
to do, and it figures out how to do it.  Or at least that's what the SQL
pundits will tell you.  The truth is a bit trickier.  Whenever it
becomes clear that SQL makes poor decisions, then we get a new
"optimization" capability.  And so now the trick is not how to write the
most sensible code, something you can teach any programmer, but instead
how to pick the correct optimization parameters - parameters which can
have completely different effects based on things like the content of
your database, much less the platform.  These parameters may not even be
supported on other platforms, thus the red herring nature of the whole
platform independence argument: the very things which make SQL perform
adequately may be contrary to the primary reason for using it in the
first place.  <sigh>


> I think this topis is great, and I hope to learn alot from this
thread.

Unfortunately, here the conversation is already long gone and into the
archives.  It's good stuff to be certain, but I want something more
permanent, so I'm going to pursue this in more detail on the IAAI
website.

Joe Pluta
iSeries Application Architecture Initiative
http://forums.plutabrothers.com/IAAI