ストアドプロシージャを使用するかどうかは、バーでの宗教的または政治的な議論です。
実行する必要があるのは、アプリケーションレイヤーを明確に定義し、それらの境界を越えないことです。ストアドプロシージャには、データベースの外部でクエリを実行する場合に比べて、いくつかの長所と短所があります。
利点1：ストアドプロシージャはモジュール式です。これは、メンテナンスの観点からは良いことです。アプリケーションでクエリの問題が発生した場合、GUIコードの多くの行に埋め込まれたクエリよりもストアドプロシージャのトラブルシューティングがはるかに簡単であることに同意するでしょう。
利点2：ストアドプロシージャは調整可能です。データベースを処理するプロシージャをインターフェイスで機能させることにより、GUIソースコードを変更してクエリのパフォーマンスを向上させる必要がなくなります。フロントエンドインターフェイスに対して透過的な、結合メソッド、異なるテーブルなどの観点から、ストアドプロシージャに変更を加えることができます。
利点3：ストアドプロシージャは、サーバー側の機能をクライアント側から抽象化または分離します。 GUIコードを使用してクエリを作成するよりも、プロシージャを呼び出すようにGUIアプリケーションをコーディングする方がはるかに簡単です。
利点4：ストアドプロシージャは通常、データベース開発者/管理者によって作成されます。これらの役割を担っている人は、通常、効率的なクエリとSQLステートメントの作成に精通しています。これにより、GUIアプリケーション開発者は、アプリケーションの機能的およびグラフィカルなプレゼンテーション部分でスキルを活用できるようになります。従業員に最適なタスクを実行させると、最終的にはより優れた全体的なアプリケーションを作成できます。
これらすべてを念頭に置いて、いくつかの欠点があります。
短所1：広範なビジネスロジックと処理を伴うアプリケーションは、ロジックが完全にストアドプロシージャに実装されている場合、サーバーに過度の負荷をかける可能性があります。このタイプの処理の例には、データ転送、データトラバーサル、データ変換、および集中的な計算操作が含まれます。このタイプの処理は、データベースサーバーよりもスケーラブルなリソースであるビジネスプロセスまたはデータアクセスロジックコンポーネントに移動する必要があります。
短所2：すべてのビジネスロジックをストアドプロシージャに入れないでください。 Sp言語でビジネスロジックを変更する必要がある場合、アプリケーションのメンテナンスと敏捷性が問題になります。たとえば、複数のRDBMSをサポートするISVアプリケーションは、システムごとに個別のストアドプロシージャを維持する必要はありません。
短所3：ストアドプロシージャの作成と保守は、ほとんどの場合、すべての開発者が所有しているわけではない特殊なスキルセットです。この状況は、プロジェクト開発スケジュールにボトルネックをもたらす可能性があります。
私はおそらくいくつかの長所と短所を見逃しているでしょう、コメントしてください。