動的 SQL は以下の場合に使用します。
動的 SQL サポート・ステートメントは、文字ストリング・ホスト変数とステートメント名を引き数として受け入れます。ホスト変数には、テキスト形式で動的に処理される SQL ステートメントが入っています。ステートメント・テキストは、アプリケーションのプリコンパイル時には処理されません。実際、ステートメント・テキストは、アプリケーションのプリコンパイル時には必要ありません。その代わりに、SQL ステートメントはプリコンパイルの段階でホスト変数とみなされ、その変数はアプリケーションを実行する間参照されます。このような SQL ステートメントを動的 SQL と呼びます。
動的 SQL サポート・ステートメントでは SQL テキストが入っているホスト変数を実行可能形式に変換し、ステートメント名を参照して操作しなければなりません。それらのステートメントは以下のとおりです。
アプリケーションは、ほとんどの SQL ステートメントを動的に実行することができます。サポートされている SQL ステートメントの全リストについては、 表 37 を参照してください。
注: | 動的 SQL ステートメントの内容は、静的 SQL ステートメントの場合と同じ構文に従っていますが、以下の点が異なります。
|
パフォーマンスのために静的 SQL または動的 SQL のどちらを使用するかは、プログラマーにとって常に関心の高い問題です。もちろんこれは、ユーザーの状態に基づいて決定されます。静的 SQL と動的 SQL のどちらを使用するかを決めるときには、 表 6 を参考にしてください。セキュリティーなどの問題は静的 SQL に影響を与えますし、 DB2 CLI を使用するか CLP を使用するかなどの環境の問題は、動的 SQL に影響を与えます。
決定する際には、ある特定の状況下で静的 SQL または動的 SQL のどちらを選んだらよいかに関して、以下の提案を考慮してください。次の表に「両方」とある場合は、静的 SQL と動的 SQL のどちらでも変わりがないことを示します。この情報はあくまでも一般的な提案に過ぎないことに注意してください。どちらを選ぶにしても、ご使用のアプリケーションの本来の用途や作業環境を考慮に入れる必要があります。はっきりしない場合は、まずステートメントを静的 SQL としてプロトタイプ化してから、次に動的 SQL としてプロトタイプ化し、その違いを比較することが最善の方法です。
考慮事項 | 推奨 SQL |
---|---|
SQL ステートメントを実行する時間
|
|
データの均一性
|
|
範囲 (<、>、BETWEEN、LIKE) 述部
|
|
繰り返し実行
|
|
照会の種類
|
|
実行時環境 (DML/DDL)
|
|
RUNSTATS の使用頻度
|
|
一般に、動的 SQL を使用したアプリケーションは、使用前に SQL ステートメントをコンパイルする必要があるため、 SQL ステートメント当たりの始動 (初期) コストが大きくなります。コンパイルを行うと、動的 SQL の実行時間は静的 SQL の場合と同じですが、最適化プログラムがより優れたアクセス・プランを選択することによりもっと速くなることがあります。初期のコンパイル・コストは、動的ステートメントを実行するたびに低減されます。複数のユーザーが同じステートメントを用いて同じアプリケーションを実行しているなら、ステートメントを発行した最初のアプリケーションだけにステートメントのコンパイル・コストが生じます。
DML と DDL が混在している環境では、アプリケーションの実行中にシステムがステートメントを暗黙のうちに再コンパイルすることがあるため、動的 SQL ステートメントのコンパイル・コストが変わる可能性があります。混合環境では、静的 SQL と動的 SQL との間の選択はパッケージが無効にされる頻度にも影響してきます。 DDL によってパッケージが無効にされる場合は、動的 SQL のほうが便利でしょう。実際に実行する照会だけが次回の使用時に再コンパイルされ、その他の照会は再コンパイルされないからです。静的 SQL の場合は、いったん無効にされるとパッケージ全体が再バインドされます。
特定のアプリケーションが上記の特性の混合したものであり、一方の特性には静的 SQL が適しており、他方の特性には動的 SQL が適していることがあります。この場合、明確な決定方法はありませんので、最も慣れていて使用しやすい手法を用いてください。前の表の考慮事項は、重要性の高い順におおまかに掲載してあることに注意してください。
注: | 静的および動的 SQL はそれぞれ、DB2 最適化プログラムにとって重要な 2 種類に分けられます。それらは以下のとおりです。 |
これは、以下の場合にしか見られない、まれな状態です。
実際これは、実行時のパフォーマンスのオーバーヘッドがなく、 DB2 最適化プログラムの機能を十分に活用しているため、パフォーマンスの観点からは最善の組み合わせです。
これは DB2 アプリケーションの従来の継承 スタイルです。ステートメントのコンパイル中に獲得する PREPARE およびカタログ・ロックの実行時オーバーヘッドがなくなります。最適化プログラムは SQL ステートメント全体を認識しないため、残念ながら、最適化プログラムの全性能を活用することはできません。高度に均一化されていないデータ配分の場合には、特殊な問題があります。
これはランダム照会インターフェース (CLP など) 用の標準的なスタイルで、最適化プログラムに好まれるタイプの SQL です。複雑な照会の場合は、 PREPARE ステートメントにオーバーヘッドがあると実行時間が短縮されるという利点があります。パラメーター・マーカーに関する詳細については、 パラメーター・マーカーの使用を参照してください。
これは CLI アプリケーション用の最も一般的なタイプの SQL です。主な利点は、パラメーター・マーカーがあるために、 PREPARE ステートメント (主に選択または挿入) を繰り返し実行するうちに、 PREPARE ステートメントのコストを償却できるという点です。この償却は、すべての反復性のある動的 SQL アプリケーションに当てはまります。残念なことに、ホスト変数を含む静的 SQL と同様に、 DB2 最適化プログラムの一部は、情報のすべてを利用することができないために作動しません。最も効率的な方法としては、 ホスト変数を指定して静的 SQL を使用すること または パラメーター・マーカーなしで動的 SQL を使用すること をお勧めします。