× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Dynamic SQL requires additional overhead
> that static SQL does not.  In order to
use SQL with the design model given
> there is additional I/O to retrieve
all field defaults via RPG(or SQL)
> to build the SQL statement, then the
execution of the SQL statement
> that was built.

Understood and agreed. Given all that however, dynamic SQL may prove an adequate performer.

Database (& process) design have
> more impact on how SQL (or native
> I/O) performs than any other
> thing I can think of.

Absolutely. The thing that many newcomers to SQL (and my remarks are directed in that direction more than anything) tend to do is equate SQL performance to the same metrics they've used for evaluating native I/O. And that just doesn't work very well, because we programmers are very specific about creating a design and a process for specifically telling OS400 _how_ to get the records. In other words, we specifically optimise our code by the way we write it. And that I/O cost scales very linearly until we hit the thrashing point in virtual memory.

SQL is very unlike that. We don't tell SQL _how_ to get the records, we tell it _what_ records we want and then let it go do the work for us. Sometimes it makes decisions that are disastrous in terms of performance, but sometimes it does a great job. In general, newcomers to SQL can't tell how a particular statement will execute on their machine with their dataset. That means that a given SQL statement may scream when there are a hundred records, but drag when there are a thousand. The dataset make-up is crucial to SQL optimisation, and the main influence we have in that regard is the creation of indexes, not by tweaking the SQL code. It's a very different paradigm...
  --buck

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.