ストアドプロシージャは、ここ数年、一部の組織で好まれなくなっています。これらの企業がデータベースにアクセスするために推奨するアプローチは、NHibernateやEntity Frameworkなどのオブジェクトリレーショナルマッパー（ORM）を使用することです。次の2つのブログ記事では、その理由と、このパラダイムシフトがストアドプロシージャの最終的な陳腐化を示しているかどうかを探ります。

ストアドプロシージャの基本

Understanding Stored Procedures and Functions in Relational Databasesで説明されているように:

ストアドプロシージャ（略して「proc」）は、名前が割り当てられた構造化照会言語（SQL）ステートメントのセットであり、リレーショナルデータベース管理システムにグループとして格納されるため、複数のプログラムで再利用および共有できます。ストアドプロシージャはデータベース内のデータにアクセスしたり変更したりできますが、特定のデータベースやオブジェクトに関連付けられているわけではありません。この疎結合は、異なる目的だが同様の目的でprocを簡単に再利用できるため、有利です。

これまでのところ便利なツールのように思えますが、次のセクションで説明するように、誰もが納得しているわけではありません。

ストアドプロシージャの欠点

ストアドプロシージャには長い間確立された利点がありますが、ストアドプロシージャの反対者は、次のような多くの欠点を指摘しています。

• バグが発生しやすい：ストアドプロシージャはアプリケーションロジックをカプセル化するため、より適切に管理およびテストできるアプリケーションコードに移動する必要があります。ストアドプロシージャのテストには固有の課題があるため、非常に厄介なバグの原因になる可能性があります。
• 実装の違い：ストアドプロシージャの実装は、ベンダーごとに異なります。多くのDB開発者はOracleのストアドプロシージャが最高品質であると考えている一方で、MySQLなどの他の製品のプロシージャはあまりよく考えられていません。
• 要件の変化：ストアドプロシージャの元の使用例の1つは、ネットワークトラフィックを削減することでした。ただし、今日の超高速ネットワーク速度では、これはかつてほど大きな問題ではありません。そのため、アプリケーションロジックをストアドプロシージャにドロップすると、時期尚早の最適化になる可能性があります。
• 保守が難しい：ストアドプロシージャは、アプリケーションコードよりも開発と保守に多くの作業が必要になる傾向があります。まず、各テーブルの作成、取得、更新、および削除の操作を実行するための個別のストアドプロシージャに加えて、作成するクエリごとに個別のストアドプロシージャが必要です。次に、各ストアドプロシージャを呼び出すためのクラスやメソッドをコードに実装する必要があります。これをO/Rマッパーと比較してください。O/Rマッパーが必要なのは、クラス定義、データベーステーブル、マッピングファイルだけです。実際、最新のORMは、個別のマッピング定義の必要性を排除するコンベンションベースのアプローチを使用しています。
• コードの重複：ストアドプロシージャでは、データベーステーブルの列を6回以上参照する必要があるため、DRY（Don't Repeat Yourself）原則に違反する必要があります。さらに、オブジェクトをパラメータとしてほとんどのストアドプロシージャに渡すことはできません。文字列、整数、日付／時刻などの単純な型のみです。そのため、膨大なパラメータリストを回避することは事実上不可能です（12以上が一般的です）。

ストアドプロシージャの最も頑固な反対者でも、状況によっては今もストアドプロシージャを使用しています。例えば、ストアドプロシージャは、データベースのハウスキーピングやレポート作成に最適です。そうでなければ、開発者はそれらをアプリケーションに統合する十分な理由を持つべきです。

今後

アプリケーションコードと、NHibernateやEntity Frameworkなどのオブジェクトリレーショナルマッパー（ORM）を優先してストアドプロシージャを避ける理由をいくつか聞いて、あなたはこれが正しい方法であると確信しているかもしれません。まあ、まだ切り替えないでください。次回の記事では、ストアドプロシージャを放棄する場合と使用し続ける場合の両方について、さらにいくつかの動機を検討します。それでも変更したい場合は、少なくとも、関連する全ての問題をより完全に理解することができるでしょう。