SQL プロシージャーまたは SQL 関数を使用する場合の判断

• 機能要件が SQL 関数により満たされ、SQL プロシージャーが提供するフィーチャーを後から必要とする見込みがない場合。

• パフォーマンスが優先され、ルーチン内に含まれるロジックが照会だけで構成されるか、または単一の結果セットだけを戻す場合。

  照会、または単一の結果セットの戻りしか含まれていない場合、SQL 関数のコンパイル方法により、SQL 関数は論理的に同等の SQL プロシージャーよりパフォーマンスがよくなります。

  SQL プロシージャーでは、SQL プロシージャーの作成時に各照会がパッケージ内の照会アクセス・プランの選択肢になるように、SELECT ステートメントおよび全選択ステートメントの形式の静的照会は個別にコンパイルされます。 SQL プロシージャーが再作成されるか、またはパッケージがデータベースに再バインドされるまで、このパッケージの再コンパイルはありません。 これはつまり、照会のパフォーマンスが、SQL プロシージャー実行時より前の時点でデータベース・マネージャーが入手できる情報に基づいて決定されるので、最適化されていない可能性があるということを意味します。 さらに、SQL プロシージャーでは、データを照会または変更するプロシージャー・フロー・ステートメントの実行と SQL ステートメントの実行との間でデータベース・マネージャーが転送を行う場合、小規模なオーバーヘッドが伴います。

  ただし、SQL 関数はそれらを参照する SQL ステートメント内で展開およびコンパイルされます。つまりこれは、ステートメントに応じて動的に実行される SQL ステートメントのコンパイルごとに、それらがコンパイルされることを意味します。 SQL 関数はパッケージとは直接関連付けられないので、データを照会または変更するプロシージャー・フロー・ステートメントの実行と SQL ステートメントの実行との間でデータベース・マネージャーが転送を行う場合、小規模なオーバーヘッドはありません。

以下の場合は SQL プロシージャーのインプリメントを選択します。

• SQL プロシージャーでのみサポートされる SQL PL フィーチャーが必要である場合。 これには、出力パラメーター・サポート、カーソルの使用、複数の結果セットを呼び出し元に戻す機能、フル条件処理サポート、トランザクションおよびセーブポイント制御、その他のフィーチャーが含まれます。
• SQL プロシージャーでのみ実行できる非 SQL PL ステートメントを実行する場合。
• データを変更したいが、必要とする関数のタイプでデータの変更がサポートされていない場合。