データベースレイヤーにアプリケーションロジックを配置することに対する、またはそれに対する議論は何ですか？[閉まっている]

ほとんどのソフトウェア開発者は、アプリケーションロジックをアプリケーションレイヤーに保持することを望んでおり、おそらくここに保持するのが自然であると感じるでしょう。データベース開発者は、トリガーおよびストアドプロシージャとして、アプリケーションロジックをデータベース層に配置したいと考えているようです。

個人的には、アプリケーション層にできるだけ多くの層を残して、層のデバッグを容易にし、層の責任を分離しておくことを好みます。

これについてどう思われますか。また、データベースレイヤーに実装しても問題ない、またはすべきでないものは何ですか？

編集この質問は、DBAの観点からdba.seでもカバーされています。Programmers.seとdba.seの対象者とバイアスは異なるため、将来の読者は、自分に最適なものを決定する前に両方の回答を確認することをお勧めします。

頭の中で、アプリケーション層にロジックを配置することの利点。

1. テスト容易性。これは実際にはそれ自身で十分な理由になるはずです。
2. より良いコード構造。SQLで適切なオブジェクト指向アーキテクチャーに従うことは非常に困難です。これにより、通常、コードの保守も容易になります。
3. コーディングが簡単。使用している言語に応じて利用可能なさまざまな言語機能があるため、通常はアプリケーション層でコーディングする方が簡単です。
4. コードの再利用。データベース内のコードを共有するよりも、ライブラリとコードを共有する方がはるかに簡単です。

ストアドプロシージャでバージョン管理を使用することは可能ですが（たとえば、RedgateデータベースツールはTFSと統合されます）、アプリケーションコードの場合ほど簡単ではありません。

私のデフォルトの位置は、ロジックをデータベース層から遠ざけることですが、データベースにロジックを実装する方が効率的である場合があります。その場合は、このコードへの変更を追跡できることを確認する必要があります。

私が働いていたある会社では、本番環境へのコードのリリースに関係する多くの赤字があり、コードリリースにDBAが関係することは常に悪夢でした。常に困難なDBAに対処する必要をなくすために、アプリケーションレイヤーにロジックを常に配置します。それは完全に不十分な理由ですが、必要性から派生したものです。

DBにアプリケーションロジックを配置することは、私にとって悪い考えのように思えます。OTOHがDBにロジックを置くことは、特にDB状態の維持の一部です（たとえば、非正規化されたテーブルを更新するトリガー/プロシージャ）は、非常に異なる命題です。

または、これは次のように表現できます。データベースを実際にどのように動作させるかを、データベースをどのように調べたいかを抽象化するために必要なロジックを配置するための適切な引数があります。

両方の質問を読んだので、私たちはすべて1つの重要なポイントを見逃したのではないかと思います。正しい答えは、開発しているソフトウェアの種類によって異なります。DBAグループは、主にビジネスに不可欠なエンタープライズソフトウェアシステムで作業する傾向があり、その答えはその世界で必要なものを反映する傾向があります。これらのタイプのアプリケーションに必要なものと、次の「Facebook」アプリケーションに必要なものとでは大きな違いがあります。ウォールポストをいくつか失えば大したことではありません。注文や他の金融取引をいくつか失えば大したことではありません。

COTS（市販の市販）の世界で働く人々は、販売上の理由からデータベースにとらわれないことが必要になる傾向があります。社内で開発および保守されるエンタープライズアプリケーションは、アップグレードを除き、データベースバックエンドを変更する必要はほとんどありません。

また、エンタープライズアプリケーションは、多くの場所からの入力がある傾向があり、データベースが唯一の共通点です。私が働いているシステムには、それにアクセスする何百もの異なるアプリケーションがあり、クライアントデータのインポート、クライアントおよびデータウェアハウスへのデータのエクスポートが何百もあり、複数のレポートシステムを使用しています。1つのレコードを追加するときにうまく機能するコードは、20,000,000をインポートしなければならないときに失敗します。アプリケーションレイヤーを一度使用することを余儀なくされたのは、それがロジックが存在する場所であり、18時間後にプロセスを停止しなければならなかったためです。テーブル内のすべてのデータレコードに適用されるロジックは、誰もが使用するデータレイヤーを1つ持つことができない場合、データベース内に存在する必要があります。

逆に、1つのアプリケーションのみがデータを消費し、そのデータが会社の生命線ではないか、または一時的なものである場合、ルールは異なり、アプリケーションにすべてのロジックを配置する方が理にかなっています。

長い。下部の要約を参照してください。

RDBMS

RDBMSは、リレーショナルデータベース管理システムの略です。リレーショナルデータベースを管理するシステムです。データはそこに保存されます。データ。ビジネスロジックとは言いません。

ビジネスプロセス

ビジネスロジックとはどういう意味ですか？私にとって、それは論理的な用語でのビジネスプロセスの説明です。

プロセスは、定期的に発生するビジネスアクティビティであり、アドホックではなくなります。これらはビジネスごとに異なります。

ここでビジネスの上限を設定し、ビジネスの意味を説明しましょう。ある人にとっては、これは驚きになるかもしれません。

ビジネス

ビジネスは、価値、より具体的には取引可能な価値の創造を達成するために実行される活動の合計です。これは、コンバイン、マグロのサンドイッチ、または銀行サービスの提供を意味します。世界の大部分の国では、非資本主義システムであっても、人々はお金の価値を最大限に引き出したいため、これらの価値ある商品やサービスの異なるプロバイダー間で競争があります。競争は通常、価格、品質、および可用性に依存します。

簡単な迂回：2日間で4000万個のリベットが必要です。通常のベンダーよりも価格がいくら安くても、PayPalアカウントでインターネット上の誰かに注文することはありません。

プロセス知識

ご想像のとおり、この「価値」の実現に関与するプロセスは、ほとんどが経営者の頭の中にあります。その一部は紙の上に置かれ、会社のポリシーと手順として使用されます。その一部は企業顧問の頭の中に住んでいます。その多くは、部門、部門、チームを運営している人々、機械、レジ、オーブン、トラックを運営している人々の頭の中に住んでいます。その小さなサブセットは、ソフトウェアのビジネス要件に基づいて決定され、さらに小さなサブセットはコンピューターシステムに実装されるまでに正確です。

最終的に、コードに表示されるビジネスロジックは、ビジネスを実行するものではなく、ビジネスのアプリケーションを実行するものです。実際の人の中の実際の脳は、実際のビジネスプロセスを保持しており、脳のプロセスがコンピューターのプロセスよりも正確であることを理解するのに問題はありません。余談ですが、ほとんどの企業のポリシーと手順さえあれば、おそらくビジネスを運営できません。非常に多くの場合、これらは非常に不正確ですが、非常に不正確です。

したがって、最終的には、ソフトウェアにコーディングされるのはアプリケーションロジックです。また、データベース管理システムのベンダーが大々的に主張しているため、人々はそれをデータベースに入れたいと考えています。

アプリケーションロジック

私はノーと言います。アプリケーションロジックはアプリケーション内にとどまります。データは非常に正規化された方法でデータベースに格納され、レポートおよびドリルとロールアップおよびピボットとキュービングのためにデータウェアハウスにETLされます。

データ

また、データはアプリケーションよりも長持ちするため、データの正規化作業はアプリケーション固有でなく、ビジネス固有でなく、ビジネス全般である必要があります。状態コードを保存しますか？INCITS 38：2009（http://www.census.gov/geo/www/ansi/statetables.html）を使用する必要があります。これは、ビジネス全体に移植可能であるためです。これにより、複数のアプリケーションがデータを操作しやすくなります。

NoSQL？

テーブルレイアウトからトリガー、ストアドプロシージャ、データ形式に至るまで、アプリケーションのコードの一部としてデータベースを扱う場合、実質的にエンタープライズデータベースを、栄光のあるフラットファイル構造である栄光のBerkleyDBとして使用しています。これは本当に永続化されたリストです。これは基本的にNoSQLが行っていることです。ルートに戻りますが、マルチプロセス、永続的、耐障害性のある方法で実行します。

実際のコード

いいえ、データベースを現在および将来の複数のアプリケーションのデータの共通リポジトリとして扱う必要があります。今、私は私の議論の核心に来ます。ビジネスプロセスは、市場、政治、ファッションの気まぐれによって変化します。非常に多くの場合、コンピューターサイエンスグレードの言語（Java、C＃、C ++など）で管理できるコーダーよりも速く変更され、最終的に会計部門またはマーケティング部門のExcelスプレッドシートでVBAで記述されます。（そしてそれが派手なvlookupsで表現できない場合のみ...）

データベースの劣化

データがうまく編成されていれば、データはあまり変化しません。ビジネスロジックは非常に速く変化します。データベースにビジネスロジックを配置することにより、データベースの価値が低下します。これは、データベースがすぐに古くなって不正確になるためです。

概要

ビジネスプロセスはアプリケーション内に存在し、ビジネスプロセスはより頻繁に変化するため、データはアプリケーションよりも長く存続する必要があります。データベースにビジネスロジックを含めると、その寿命と全体的な価値が低下します。

警告

私はdba-ingを共有し、dba.seで答えを読みましたが、正直なところ、彼らが話しているのはデータの整合性の問題とパフォーマンスの問題です。会社のデータに触れる人は、dba、プログラマー、または読み取り/書き込みアクセス権を持つSASシニアアナリストなど、何をしているのかを知っている必要があることに完全に同意します。

また、コーダーがSQLを知っていることを推奨していることにも注意しました。同意する。これはコンピュータープログラミング言語なので、コンピュータープログラマーがそれを知りたくない理由はわかりません。

後で、それについて考えた後

妥協点は、APIを作成し、そのAPIにデータフローを管理させることだと思います。アプリがテーブルに直接接続することを許可できない場合は、少なくともアクセスメカニズムを最新の言語にすることができます。

劇的に聞こえる危険性があるので、データベース内のアプリケーションロジックのアイデアに本当に恐れています。ここでの多くの回答は、ソフトウェア開発の利点に焦点を当てているため、簡潔にするために、責任の分割によってもたらされる利点に焦点を当てます。

データベースは、冗長なデータを最小限に抑え、データの論理的な関係を作成しながら、情報を保存およびアクセスする効率的な手段を提供します。データベースロジックは実稼働レベルのビジネスロジックを実装できる可能性がありますが、個人的な意見としては、データベースのそれぞれの長所を活用しながら、複数のアプリケーションでデータを効果的に活用できるように、データベースはできるだけアプリケーションに依存しないようにする必要がありますエンジン対アプリケーションの実装言語の長所。

DBAスタック交換の1人のユーザーはこれを述べました...

データベース内のすべてのユーザーとすべてのアプリケーションに適用する必要があるすべてのロジックが必要です。それはそれを置く唯一の健全な場所です。

私が働いた最後のフォーチュン500には、少なくとも25の言語で記述されたアプリケーションがOLTPデータベースにアクセスしていました。これらのプログラムの一部は、1970年代に生産に移行しました。

...これは、DRY原則への違反を示しているという彼の信念が続きます。

これは、ビジネスロジックの繰り返しではなく、ビジネスレイヤーとデータレイヤーの責任の明確な分割によって提供される柔軟性の完璧な例である可能性が高いと思います。

彼らのOLTBデータベースは、数十年にわたって25以上のアプリケーションにデータを確実かつ効率的に提供してきました！すごい！（行く方法！）

私は、データが多くの異なるアプリケーションにコンテンツを提供するのに十分に不可知であると仮定することができます。これらの開発者がデータベースロジックを使用して何かを一緒にハッキングしようとした場合、ほとんど不可能なことです。

他の回答が示しているように、データベースにプログラムを実装しない他の多くの理由があります。私はそれがうまくいくと確信していますが、最も可能性の高い結果は、数十年の安定ではなく、数十年の後悔です。

データベースに依存しないアプリケーションでは、データベースからすべてのロジックが必要です。多くの異なるデータベースプロバイダー向けのコードを構築および保守することは非常に困難です。

優れた開発では、データベースにロジックの一部を、アプリケーションにロジックのほとんどを配置することで、データベースの整合性と速度のバランスを取ります。

同じクエリが多くのアプリケーションで繰り返し使用され、その後、ストアドプロシージャに属する可能性があります。

行が挿入および更新されるときにハウスキーピングフィールドが設定されていることを確認することは、DBAの責任です。トリガーが使用されます。

一方、ビジネスロジックがある場合は、アプリケーションに含める必要があります。可能な場合は、ストアドプロシージャを呼び出して、必要なフィールドの正確な量を使用して、目的のフィルタリングされたレコードセットを返します。それ以上でもそれ以下でもありません。

チーム間のコミュニケーションの問題であり、それぞれの可能性の長所と短所を認識することの問題です。

私の意見は次のとおりです。DBのアプリケーションロジックを深くしすぎないでください。

一部の取引システムは、基本的にデータベースに配置されたスクリプトで既存の機能を拡張する方法を提供します。これに関する私の経験は、少なくともマルチユーザー設定ではかなり否定的です。

ロジックを簡単に変更できるようにしたいので、データベースにロジックを配置します。

• バージョン管理はどうしますか？
  • コード履歴とは何ですか？変更点は何ですか？誰によって？
  • 同じコードフラグメントの変更をどのように処理しますか？
• 一貫したコード状態をどのように識別して保証しますか？

追加のファイルベースのVCSでこれを追跡できますが、データベースの利点は何ですか？

ほとんどのアプリケーションには、統合を提供する何らかの方法が必要です。理想的には、完全なAPI、Webサービス、または少なくともビジネスロジックを含むいくつかのデータベースオブジェクトを利用可能にする必要があります。誰もがAPIを構築する時間/リソースの立場にないため、妥協する必要があります。