SQL ルーチンまたは動的に準備されたコンパウンド SQL ステートメントを使用する場合の判断

パフォーマンス

動的に準備されたコンパウンド SQL ステートメントが機能上の要件を満たせる場合、こちらを使用する方がよいでしょう。なぜなら、動的に準備されたコンパウンド SQL ステートメントに含まれる SQL ステートメントは、1 つのブロックとしてコンパイルされて実行されるからです。 また一般的に、このステートメントのほうが、論理的にこれに相当する SQL プロシージャーに対する CALL ステートメントよりもパフォーマンスは良くなります。

SQL プロシージャーの作成時に、このプロシージャーはコンパイルされてパッケージが作成されます。 SQL プロシージャーのコンパイルの時点で、データへのアクセスに最適な実行パスが、そのパッケージの中に入れられます。 動的に準備されたコンパウンド SQL ステートメントは、実行時にコンパイルされます。 このステートメントに関しては、データへのアクセスに最適な実行パスは、最新のデータベース情報を使用して判別されます。すなわち、そのアクセス・プランのほうが、それより以前に作成された論理的にそれに相当する SQL プロシージャーのアクセス・プランよりも優れているので、パフォーマンスも向上する可能性があることを意味します。

必須論理の複雑さ

ロジックがかなり単純であって、しかも SQL ステートメント数が比較的少数の場合、動的に準備されたコンパウンド SQL ステートメント (ATOMIC を指定) 内、または SQL 関数内でインライン SQL PL を使用することを考慮してください。 SQL プロシージャーも単純なロジックを扱うことはできますが、SQL プロシージャーを使用すると、プロシージャーの作成やその呼び出しなどいくらかのオーバーヘッドが生じるので、必要がなければ使用しないのが最善です。

実行する SQL ステートメントの数

1 つか 2 つの SQL ステートメントだけを実行する場合、SQL プロシージャーを使用する利点はないかもしれません。 実際、その使用によって、このステートメントの実行に必要なパフォーマンス全体が否定的な影響を受ける可能性があります。 1 つか 2 つの SQL ステートメントを実行するような場合は、動的に準備されたコンパウンド SQL ステートメントにおいてインライン SQL PL を使用する方が得策です。

原子性およびトランザクションの制御

別の考慮事項として、原子性があります。 コンパウンド SQL (インライン化) ステートメントは、アトミックである必要があります。 コンパウンド SQL (インライン化) ステートメントでは、コミットおよびロールバックはサポートされません。 トランザクション制御が必要な場合や、セーブポイントへのロールバックのサポートが必要な場合、SQL プロシージャーを使用する必要があります。

セキュリティー

考慮事項には、セキュリティーもあります。 SQL プロシージャーを実行できるのは、そのプロシージャーに対する EXECUTE 特権を付与されたユーザーのみです。 これは、特定のロジックをだれが実行できるかに関して制限を設けることが必要な場合に役立ちます。 動的に準備されたコンパウンド SQL ステートメントを実行できるかどうかに関しても管理できます。 しかし、SQL プロシージャーの実行許可によりセキュリティー制御の追加の層が提供されます。

フィーチャー・サポート

1 つ以上の結果セットを戻す場合、SQL プロシージャーを使用する必要があります。

モジュール性、長期性、および再利用

SQL プロシージャーは、データベースに永続的に保管されるデータベース・オブジェクトであり、これに対しては、複数のアプリケーションまたはスクリプトからの一貫性のある参照が可能です。 動的に準備されたコンパウンド SQL ステートメントは、データベースには保管されないので、その中のロジックをすぐに再利用することはできません。