I would like to support that statement.
Static SQL has its benefits, especially that for high volume transactions the
access path has not to be determined on every execution. But sometimes dynamic
SQL is even better, because input values are known and better filter factors can
be calculated and so on. On some complex queries I saw better results (faster
queries) with dynamic vs. static. So I don't quite understand the problems some
people have with dynamic SQL in DB2. If the time for PREPARE and DESCRIBE etc.
is low with respect to query execution time, it doesn't really matter.
And if the SQL is built by a stored procedure and the user "outside" is
separated from the full power of SQL (that is, he or she can only specify WHERE
conditions), there is no security problem.
Kind regards
Bernd
Am Freitag, 4. März 2011 15:58 schrieben Sie:
> Given that the "mainframe people" will be writing the dynamic SQL, and
> given the improvements over the last few releases of DB2 (and the gradual
> convergence of static and dynamic SQL (and THAT particular journey is not
> finished yet)) I don't see any significant problems - and many advantages
> (both in DB2 terms and politically)
|