ストアドプロシージャは3層の分離に違反していますか？
ストアドプロシージャはビジネスロジックであるのに対し、データベースはデータレイヤーに属しているため、データベースのストアドプロシージャにビジネスロジックを含めると、3層の分離アーキテクチャに違反すると同僚から聞いたことがあります。
ストアドプロシージャがなければ、世界は非常に厳しい場所になると思います。
それらは本当に3層分離に違反していますか？
あなたの同僚はアーキテクチャと実装を融合しています。
多層アプリケーションの背後にある考え方は、特定の種類の処理（ストレージ、ビジネスロジック、プレゼンテーション）をカプセル化し、明確に定義されたインターフェイスを使用して相互に通信する部分に分割されるということです。非オブジェクト指向言語でのオブジェクト指向プログラミングに似た処理を正常に実行できるのと同じように、データベースサーバーなどの1つの環境内の複数の層で同じことを実行できます。これらのいずれかを正常に実行することで共通していることは、関与する妥協への配慮、規律、理解の必要性です。
2つの層がデータベースに実装されている3層アプリケーションを見てみましょう。
- データ層： 4つの標準テーブル操作（
INSERT、UPDATE、DELETEおよびSELECT）を使用してアクセスされるデータベーステーブルで構成されます。 - ロジック層：ビジネスロジックのみを実装し、上記の方法のみを使用してデータ層にアクセスするストアドプロシージャで構成されます。
- プレゼンテーション層：ストアドプロシージャの呼び出しのみを行うことでロジック層にアクセスするコードを実行するWebサーバーで構成されます。
これは完全に許容できるモデルですが、いくつかのトレードオフが伴います。ビジネスロジックは、データ層にすばやく簡単にアクセスできるように実装されており、データベース外のロジック層によって「難しい方法」で実行する必要があることを実行できる場合があります。あきらめるのは、いずれかの層を他のビットのテクノロジーや気楽な実装に簡単に移動する機能です（つまり、層は、データベースで使用できるが定義されたインターフェースの外側にある機能を使用しないように特に注意する必要があります）。 。
この種のものとそれがもたらすトレードオフが特定の状況で許容できるかどうかは、あなたとあなたの同僚があなたの判断を使って決定しなければならないことです。
ストアドプロシージャは、ビジネスロジックをRDBMSレイヤーに組み込むことにより、3層分離の違反をコーディングできるほど強力です。ただし、これはユーザーの決定であり、ストアドプロシージャの固有の欠陥ではありません。アプリケーションロジックをアーキテクチャのアプリケーションレイヤーに維持しながら、SPをデータレイヤーのニーズに対応するように制限できます。
ストアドプロシージャ（特に、トリガーのグループ）にビジネスロジックを含める必要がある場合、分離のルールにはまれですが重要な例外があります。これは、アプリケーションが何百万もの行に触れる大量のオンザフライデータ集約を生成する必要がある場合に発生します。このような場合、ビジネスレイヤーで使用するために事前に集計されたデータを維持するようにトリガーを設定できます。これは、事前集計を行わないと、アプリケーションが許容できないほど遅くなる状況でのみ実行する必要があります。
2004年からのアトウッドのアドバイスは今日も当てはまりますが、ORMのメリットを享受できるのは私たちだけです。
http://blog.codinghorror.com/who-needs-stored-procedures-anyways/
ストアドプロシージャは、データベースアセンブリ言語と考える必要があります。最もパフォーマンスが重要な状況でのみ使用してください。ストアドプロシージャに頼ることなく、堅牢で高性能なデータアクセスレイヤーを設計する方法はたくさんあります。パラメータ化されたSQLと単一の首尾一貫した開発環境に固執すれば、多くのメリットを実感できます。
概要：ストアドプロシージャの使用方法とビジネス要件によって異なります。
3層アーキテクチャを使用するプロジェクトは多数あり、ビジネス要件の性質によっては、一部の操作をデータ層にシフトする必要がある場合があります。
用語について言えば、一般的にこれらの層は次のように説明されています。
- プレゼンテーション層、またはユーザーサービスレイヤー-ユーザーにアプリケーションへのアクセスを提供します。
- 中間層、またはビジネスサービスレイヤー-ビジネスルールとデータルールで構成されます。
- データ層、またはデータサービスレイヤー-通常はデータベースまたは永続的なストレージに保存されている永続データとやり取りします。
通常、特定のアーキテクチャでは、中間層またはビジネスサービスレイヤーは、ビジネスルールとデータルールで構成されます。ただし、データ層で実行される重いセットの基本操作やデータルールをシフトすることは、ストアドプロシージャのセットを通じて大きな違いをもたらすことがあります。
3層設計の利点は次のとおりです。
アプリケーションのライフサイクル中、3層アプローチは、再利用性、柔軟性、管理性、保守性、スケーラビリティなどの利点を提供します。作成したコンポーネントとサービスを共有して再利用でき、必要に応じてそれらをコンピューターのネットワーク全体に配布できます。大規模で複雑なプロジェクトをより単純なプロジェクトに分割し、それらを異なるプログラマーまたはプログラミングチームに割り当てることができます。また、サーバーにコンポーネントとサービスをデプロイして変更に対応できるようにすることもできます。また、アプリケーションのユーザーベース、データ、トランザクション量の増加に応じて、それらを再デプロイすることもできます。
したがって、それは実際にはケース・ベースのアプローチであり、それ自体にトレードオフがあります。ただし、Microsoftの設計ガイドライン 層アーキテクチャモデル は、ビジネスロジックを中間層に保持することをお勧めします。
層は実際には異なるマシンを意味し、層は異なる論理的分離を意味します。ストアドプロシージャを使用すると、同じ層にデータレイヤーと（少なくとも一部の）ビジネスロジックレイヤーがあります。ストアドプロシージャにビジネスロジックを配置すると、3階層アーキテクチャに違反しますが、3層アーキテクチャに違反しているかどうかは疑問です。確かなことの1つは、それが懸念の分離の良い例ではないということです。
レイヤーは、ソフトウェアソリューションを構成する要素の論理的な構造化メカニズムです。層は、システムインフラストラクチャの物理的な構造化メカニズムです。 （ 参照 ）
私の意見では、データベースでのビジネスロジックの構築には2つの大きな問題があります。
コードとライブラリ：C＃、Javaなど）に比べて、SQL、PL/SQL、TSQLなどでプログラミングできるプログラマーの数は少なくなります。プログラミング言語には、優れたIDE、ライブラリとフレームワーク。
水平方向のスケーラビリティ：システムをスケーリングできる唯一の方法は、データベースが配置されている物理サーバーをより強力な物理サーバーに変更することです。これはかなり高価です（RAMが64 GBのサーバー）。リレーショナルデータベースの水平方向のスケーリングは非常に悪く、費用もかかります。一方、OOで構築されたサーバーのビジネスロジックでは、サーバーを多くのノードに配置することで、水平方向にかなり適切にスケーリングできます（Java多くのアプリケーションサーバーがこれをサポートしています）。