ストアドプロシージャは3層の分離に違反しますか？

データベースはデータレイヤーに属しているのに対し、ストアドプロシージャはビジネスロジックであるため、データベース内のストアドプロシージャにビジネスロジックがあると、3層分離アーキテクチャに違反するという話を私の同僚から受けました。

ストアドプロシージャがなければ、世界は非常に厳しい場所になると思います。

彼らは本当に3層分離に違反していますか？

同僚は、アーキテクチャと実装を混同しています。

多層アプリケーションの背景にある考え方は、特定の種類の処理（ストレージ、ビジネスロジック、プレゼンテーション）をカプセル化し、明確に定義されたインターフェイスを使用して相互に通信する部分に分割することです。非オブジェクト指向言語でオブジェクト指向プログラミングに似たことを成功させることができるように、データベースサーバーなどの1つの環境内の複数の層で同じことを行うことができます。それらのいずれかを成功裏に共有することは、ケア、規律、および関与する妥協の理解の必要性です。

データベースに2つの層が実装されている3層アプリケーションを見てみましょう。

• データ層： データベースのテーブルで構成さは、（4つの標準テーブル操作を使用してアクセスINSERT、UPDATE、DELETEおよびSELECT）。
• ロジック層：ビジネスロジックのみを実装し、上記の方法のみを使用してデータ層にアクセスするストアドプロシージャで構成されます。
• プレゼンテーション層： ストアドプロシージャ呼び出しのみを行うことでロジック層にアクセスするコードを実行するWebサーバーで構成されます。

これは完全に受け入れられるモデルですが、いくつかのトレードオフが伴います。ビジネスロジックは、データ層への高速で簡単なアクセスを可能にする方法で実装され、データベース外のロジック層で「難しい方法」で実行する必要があることを実行できる場合があります。あきらめるのは、いずれかの層を他のテクノロジーや気楽な実装に簡単に移動できることです（つまり、定義されたインターフェース以外ではデータベースで利用できる機能を層が使用しないように特に注意する必要があります） 。

この種のものとそれがもたらすトレードオフが与えられた状況で受け入れられるかどうかは、あなたとあなたの同僚があなたの判断を使用して決定しなければならないものです。

ストアドプロシージャは、ビジネスロジックをRDBMSレイヤーに取り込むことで、3層分離の違反をコーディングできるほど強力です。ただし、これはユーザーの決定であり、ストアドプロシージャに固有の欠陥ではありません。アーキテクチャのアプリケーションレイヤーにアプリケーションロジックを維持しながら、SPをデータレイヤーのニーズに対応するように制限できます。

ビジネスロジックを含めるためにストアドプロシージャ（具体的には、トリガーのグループ）が必要な場合、分離の規則にはまれですが重要な例外があります。これは、アプリケーションが何百万行にも及ぶオンザフライのデータ集約を大量に生成する必要がある場合に発生します。そのような場合、トリガーを設定して、ビジネス層で使用するために事前に集計されたデータを維持できます。これは、事前集計を行わないと、アプリケーションの速度が許容できないほど遅くなる場合にのみ行う必要があります。

2004年からのAtwoodのアドバイスは今日でも当てはまりますが、私たちだけがORMのメリットも得ています。

http://blog.codinghorror.com/who-needs-stored-procedures-anyways/

ストアドプロシージャは、データベースアセンブリ言語と見なされる必要があります。最もパフォーマンスが重要な状況でのみ使用されます。ストアドプロシージャに頼らずに、堅牢で高性能なデータアクセスレイヤーを設計する方法はたくさんあります。パラメーター化されたSQLと単一の一貫した開発環境に固執すれば、多くのメリットを実感できます。

概要：ストアドプロシージャの使用法とビジネス要件によって異なります。

3層アーキテクチャを使用するプロジェクトは多数あり、ビジネス要件の性質によっては、一部の操作をデータ層に移行する必要がある場合があります。

用語について言えば、一般的にこれらの層は次のように説明されます。

• プレゼンテーション層、またはユーザーサービスレイヤー-ユーザーがアプリケーションにアクセスできるようにします。
• 中間層、またはビジネスサービス層-ビジネスルールとデータルールで構成されます。
• データ層、またはデータサービス層-通常、データベースまたは永続ストレージに保存されている永続データとやり取りします。

通常、指定されたアーキテクチャの中間層またはビジネスサービスレイヤーは、ビジネスルールとデータルールで構成されます。ただし、場合によっては、一連のストアドプロシージャを使用して、重いセットベース操作やデータルールをデータ層で実行することで大きな違いが生じることがあります。

3層設計の利点は次のとおりです。

アプリケーションのライフサイクル中、3層アプローチは、再利用性、柔軟性、管理性、保守性、スケーラビリティなどの利点を提供します。作成したコンポーネントとサービスを共有および再利用でき、必要に応じてそれらをコンピューターのネットワーク全体に配布できます。大規模で複雑なプロジェクトをより単純なプロジェクトに分割し、それらを異なるプログラマーまたはプログラミングチームに割り当てることができます。また、サーバーにコンポーネントとサービスをデプロイして変更に対応し、アプリケーションのユーザーベース、データ、およびトランザクション量の増加に応じてそれらを再デプロイできます。

したがって、それは実際にはトレードオフのあるケースベースのアプローチです。ただし、Microsoftの3層アーキテクチャモデルの設計ガイドラインでは、ビジネスロジックを中間層に保持することを推奨しています。

層は実際には異なるマシンを意味し、層は異なる論理的分離を意味します。ストアドプロシージャを使用すると、同じ層にデータレイヤーと（少なくとも一部）ビジネスロジックレイヤーがあります。ストアドプロシージャにビジネスロジックを配置すると、3層アーキテクチャに違反しますが、3層アーキテクチャに違反するかどうかは疑問です。確かなことは、それが懸念の分離の良い例ではないことです。

レイヤーは、ソフトウェアソリューションを構成する要素の論理的な構造化メカニズムです。層は、システムインフラストラクチャの物理的な構造化メカニズムです。（参考）

私の意見では、データベースにビジネスロジックを構築することには2つの大きな問題があります。

1. コードとライブラリ：C＃、Javaなどよりも、SQL、PL / SQL、TSQLなどでプログラミングできるプログラマは少ないでしょう。プログラミング言語には、優れたIDE、優れたライブラリ、フレームワークの利点もあります。

2. 水平方向の拡張性：システムを拡張できる唯一の方法は、データベースが搭載されている物理サーバーをより強力な物理サーバー（64 GB RAMを搭載したサーバー）に変更することです。リレーショナルデータベースのスケールは水平方向に非常に悪く、さらに大きな費用がかかります。一方、OOで構築されたサーバーのビジネスロジックでは、サーバーを多くのノードに配置することで水平方向にかなりうまく拡張できます（Javaでは多くのアプリケーションサーバーがこれをサポートしています）。

私たちはオフィスでこの議論を何度か行ったことがあります。私はデータベース開発を支持していました。

1. Oracle Databaseを使用している場合は、PL / SQLを可能な限り使用する必要があります。投資する企業は、少なくとも10年はOracleに固執するからです。昨日はアプリケーションでOracle Formsを使用していましたが、今日は.net Webフォームを使用し、次にMVCを使用し、明日、angularjsを使用し、残りのAPIのみが必要になります。データベースに最大のロジックがある場合は、新しいフロントエンドテクノロジーに簡単に移行できます。
2. データベース開発は、非常に高速で非常に効率的なパフォーマンスです。あなたに見通しを与えるために。私たちのプロジェクトでは、7人のアプリケーション開発者と1人のデータベース開発者がいて、ロジックの80％がデータベースにありました。
3. oracleを使用している場合は、ユーティリティを使用して、データベースプロシージャをRes full Apiに直接変換できます。

アプリケーション開発者は、データベースを簡単に変更できるように、ビジネスロジックはデータベースから独立している必要があると主張しています。会社がオラクルを使用している場合、アプリケーションロジックが廃止される可能性が予想されるのではなく、他のテクノロジーに切り替える理由を私は思う。問題は、主にデータベースリソースの新しい才能が不足していることです。ほとんどの人は、mysqlまたはsqlserverを使用している単純なWebサイトを開始します。その後、これらの人はシニアリードになり、アプリケーションレイヤーと感情的に結びつきます:)彼らは理解したり議論したりしたくさえありません。