ストアドプロシージャの短所
ストアドプロシージャを使用する利点と欠点の一覧を取得したいと考えています。 SPの主な利点は、プリコンパイルされ、アプリケーションからのデータが抽象化されているようです。あなたの考えを教えてください...
修正：それらがプリコンパイルされるかどうかは、データベースによって異なります。たとえば、SQL Serverではそうではありません。ストアドプロシージャとパラメーター化されたSQLは、どちらも実行前にコンパイルされます。ストアドプロシージャは、対応する実行プランが存在する場合、実行プランを再利用することがありますが、パラメーター化されたSQLも可能です。
編集：MSDNがこれについて述べていること ：
SQL Server 2000およびSQL Serverバージョン7.0には、ストアドプロシージャのパフォーマンス上の利点の多くをすべてのSQLステートメントにまで拡張するステートメント処理への多くの変更が組み込まれています。 SQL Server 2000およびSQL Server 7.0では、ストアドプロシージャの作成時に、部分的にコンパイルされたプランが保存されません。ストアドプロシージャは、他のTransact-SQLステートメントと同様に、実行時にコンパイルされます。 SQL Server 2000およびSQL Server 7.0は、ストアドプロシージャの実行プランだけでなく、すべてのSQLステートメントの実行プランをプロシージャキャッシュに保持します。
Advantages：データベース（別の抽象化レイヤー）への「パブリックインターフェイス」を提供します。
また、すべてのクエリを同じ場所にグループ化することで、データベースのクエリ方法をDBAが簡単に確認し、それに応じてデータベースを最適化できます。
欠点：複雑なロジックを配置するのに最適な場所ではない可能性があります。ただし、複雑なロジックはストアドプロシージャではなくアプリケーションコードに属しているという考えに従って、ストアドプロシージャは単にCRUD操作になります（各テーブルには「作成」、「読み取り」、「更新」、および「削除」プロシージャがあります）。その場合、ストアドプロシージャはアプリケーションに付加価値を与えません。それらはメンテナンスを複雑にし、無駄になるだけです。
クエリはすべてグループ化されているため、クエリが使用されているアプリケーションのコンテキストを確認することは困難です。変更の影響の分析には時間がかかり、変更の実行にも時間がかかります。
したがって：ストアドプロシージャを使用して、複雑なクエリ（複雑な結合、複雑なwhere句など）をカプセル化します。ただし、複雑なアプリケーション/ドメイン/ビジネスロジックにストアドプロシージャを使用しないでください。また、CRUDにもストアドプロシージャを使用しないでください。したがって、ストアドプロシージャは、アプリケーションのすべてのクエリの標準ツールではなく、少数のケースで使用する必要があります。
ツール/テクノロジーごとにグループ化するのではなく、コードをグループ化（クエリを含む）して「機能的結合」を実現します。 DBAがクエリの方法に基づいてデータベースを最適化できるようにするには、プロファイラーを使用します。
SPを使用することで、ユーザーがテーブルに直接アクセスできるようにする必要もなくなります。すべてのアクセスはSPを介して制御できます。
短所
リファクタリングは難しいです。ストアドプロシージャの名前を変更または変更すると、悪影響が生じる可能性があります。
ストアドプロシージャの単体テストには、DBの外部のコード支援が必要です
利点
- 変更を加えるためにデプロイする必要はありません。
- いつかもっと速く
- システムの拡張が容易
現在の.Net 3.5フレームワークライブラリでは、Linqを使用してほとんどのデータベース操作を実行します。 SPの方が理にかなっている場所があるかもしれません。しかし、LinqはSPも実行するための準備をしています。
SPの欠点については、次のリンクをご覧ください-興味深い分析。ブログ投稿のコメントもチェックしてください。
http://www.spoiledtechie.com/post/Whats-up-with-Stored-Procedures-these-days.aspx
利点：ストアドプロシージャを使用すると、外部プログラムに依存することなく、データの整合性を維持し、データベースポリシーを適用できます。
欠点：デバッグをより複雑にすることができます。正しく行われないと、コピー操作中にドロップされる可能性があります。
短所
- ソース管理は面倒な場合があります。
- デバッグは難しいです。
- プロシージャに多くの機能がある場合、異なるデータベースシステム間のスワッピングが困難になります。また、異なるデータベースシステムをサポートする場合は、さらに多くの作業が発生します。
- ストアドプロシージャの開発は、特に複雑になるため、かなり特殊なタスクになる可能性があります。
ビジネスロジックの一部がデータベース側にあるため、もう1つの欠点はバージョン管理です。 v2（現在）からv1（1年前）に簡単にロールバックできますか？
実行可能な解決策は、ストアドプロシージャ名のバージョン管理です。しかし、今やデータベースは新旧のストアドプロシージャで混乱しています。
アプリケーションを構築するときにストアドプロシージャを排他的に使用するいくつかの理由：
- ストアドプロシージャは、アプリケーションと基盤となるデータベースの間のインターフェイスになります。この方法では、データベースが常駐するサーバー（通常はデスクトップマシンよりも強力）を使用して、より複雑な手順を実行できます。
- データベースの構造を変更する必要がある場合、ストアード・プロシージャーがインターフェースとして使用されていれば、アプリケーションを壊すことなくそれを行うことができます。
- 作成すると、ストアドプロシージャにはプリコンパイルされ、テスト済みのSQLが含まれます。
- クライアントまたはGUIによって生成されたSQLを使用するよりも、ストアドプロシージャを使用して複雑な操作を実行する方が簡単です。
アプリケーションコード内で同じロジックを作成するよりもストアドプロシージャを使用する場合の利点は、アプリケーションがデータベースに対して行う呼び出しの数を減らすことができることです。
ストアドプロシージャは、引数を取り、アプリケーションに結果を返すのではなく、それらの引数に基づいてさまざまな決定とアクションを行うことができます。その後、アプリケーションが決定を行い、別のアクションを実行して別のデータベース呼び出しを行う必要があると判断します。
パフォーマンスのボトルネックは、ほとんどの場合プロセス間通信です。データベースへの呼び出しを最小限にしようとしています。
利点：DBAは、アプリケーションが気にしない動作を追加できます。たとえば、各行に変更日を保存します。
利点：データベース関連のコードは、データベース作業に関心があり、熟練したスタッフによって記述される可能性が高くなります。
-ストアドプロシージャの利点
- 再利用可能で、あらゆるアプリケーションに対して透過的です。
- 安全。
- アプリケーションとデータベースサーバー間のデータトラフィックを減らします。
- アプリケーションのパフォーマンスを向上させます。
-ストアドプロシージャの短所。
- 多数の論理操作により、CPU使用率が増加します。
- デバッグが難しい。
- 開発と保守が容易ではありません。
- 複雑または柔軟なビジネスロジックの開発用に設計されていません。
利点：運用チームには、運用中の問題を監視または修正するためのフックがあります。
利点：SPは、SQLステートメントのセットを実行するために使用されます。短所：デバッグが複雑
もう1つの利点は、データベースを使用する複数のクライアントアプリケーションと環境（Web、デスクトップ、さまざまなOSに分散したレポートツールなど）が存在する可能性がある大規模なエンタープライズ環境にあります。一部のビジネスルールの変更では、データベースで変更を行うことができ、これはすべての環境で効果的です。
利点-
- 1か所に整理されている（コード全体に散りばめられていない）
- 動的クエリよりもはるかに高速
サーバーの負荷が増加します。他のアプリケーションまたは複数のアプリケーションが同じデータベースサーバーを使用している場合、速度が低下します。
簡単な答えは次のようになります。adv：T-SQLコードをカプセル化するための最も強力な構造です。 SELECTに限定されず、すべてのDMLコードをサポートします。入力を受け取り、出力を直接返すことができます。
dis：SELECTで呼び出すことはできないため、複数のレコードに対して実行することはできません。