ソフトウェア エンジニアとして、私はアプリケーション レイヤーでビジネス ロジックを記述することに強い偏見を持っていますが、通常は CRUD (Create Retrieve Update and Delete) 操作以外はほとんどデータベースに依存していません。一方、大量のビジネス ロジックがストアド プロシージャで記述されているアプリケーション (通常は古いアプリケーション) に出くわしたことがあります。そのため、データベース レイヤーでビジネス ロジックを記述することを好む人がいます。
ストアド プロシージャでビジネス ロジックを書いたり書いたりすることを楽しんでいる人のために、この方法を使用する理由は何ですか?
DB 内のビジネス ロジックを、単一のアプリケーション操作を実行するために大量のクエリと更新を実行する必要がある proc のみに真剣に制限しようとしています。それもアプリに入れるべきだと主張する人もいるかもしれませんが、私はできれば IO を抑えたいと思っています。
データベースは CRUD に最適ですが、ロジックで肥大化した場合:
可能な限り、ビジネス ロジックを最もテストとデバッグが容易な環境に保ちます。他の人の既存の回答でビジネスロジックをデータベースに保存する正当な理由がいくつかありますが、ほとんどの場合、これよりもはるかに重要です。
ビジネス ロジックをアプリケーション レイヤーに限定することは、せいぜい近視眼的です。経験豊富なプロのデータベース設計者がシステムで許可することはめったにありません。データベースには、任意のソースからのデータをどのようにデータベースに格納するかを定義するのに役立つ、制約とトリガー、およびストアド プロシージャが必要です。
データベースがその整合性を維持し、新しいデータまたはデータ変更のすべてのソースが規則に従っていることを確認する必要がある場合、データベースは必要なロジックを配置する場所です。アプリケーション層に置くことは、起こるのを待っているデータの悪夢です。データベースは、1 つのアプリケーションだけから情報を取得するわけではありません。アプリケーションのビジネス ロジックは、多くの場合、インポートによって意図せずバイパスされます (古い履歴データをシステムにインポートしたい、または多数のターゲット レコードを希望する新規顧客を獲得したと仮定すると、インターフェースを介して 100 万の可能なターゲットを入力する人は誰もいません。 1 回限りの問題 (すべての製品の価格を 10% 引き上げるなど) を修正するために、クエリ ウィンドウで行われた変更によってもバイパスされます。データの変更に適用されるはずのアプリケーション レイヤー ロジックがある場合は、そうではありません。アプリケーション層に配置しても問題ありません。データベースに悪いデータを送信してネットワーク帯域幅を浪費することは意味がありませんが、データベースに配置しないと、遅かれ早かれデータの問題が発生します。
これらすべてをデータベースに保持するもう 1 つの理由は、ユーザーが詐欺を犯す可能性があることです。すべてのロジックをアプリケーション層に配置する場合は、ユーザーにテーブルへの直接アクセスを許可する必要があります。すべてのロジックをストアド プロシージャにカプセル化すると、ストアド プロシージャで許可されていることだけを実行するように制限できます。財務記録や個人情報 (健康記録など) を格納するデータベースへのユーザーによるアクセスを許可することは考えません。2 人のデータベース管理者以外の誰もが、いかなる形や形式でも生産記録に直接アクセスすることを許可しないからです。 . 多くの開発者が認識しているよりも多くの詐欺が犯されており、設計時にその可能性を考慮している開発者はほとんどいません。
大量のデータをインポートする必要がある場合、データ アクセス レイヤーを通過すると、データベースが処理するように設計されたセットベースの操作を利用できないため、クロールへのインポートが遅くなる可能性があります。
「ビジネスロジック」という用語の使い方はかなり曖昧です。
これは、データに対する制約の実施 (別名「ビジネス ルール」) を含めることを意味すると解釈できます。これらの施行は、明確に dbms 期間に属します。
また、「新規のお客様がいらっしゃれば、1週間以内にウェルカムレターをお送りします」などと解釈することもできます。このようなものをデータレイヤーにプッシュしようとするのは、おそらく大きな間違いです。このような場合、「新しいウェルカム レターを作成する」ためのドライバーは、おそらく、新しい顧客行の挿入もトリガーするアプリケーションである必要があります。新しいデータベース行が挿入されるたびに新しいウェルカム レターがトリガーされ、突然別の会社を買収し、その会社の顧客を自社のデータベースに統合する必要があると想像してみてください。
必要に応じて、DB 層で多くの処理を行います。分析を行うために大規模なデータセットをアプリ層にプルバックしたくない操作がたくさんあります。また、すべてのインストール ポイントでアプリケーションを更新するのではなく、1 つのポイントで簡単に展開できます。ただし、アプリケーションとその機能に大きく依存します。ここには、唯一の良い答えはありません。
「ビジネス ロジック」がアプリケーション フロー、ユーザー コントロール、時限操作、および一般的に「ビジネスの実行」を意味する場合、それはアプリケーション層にあるはずです。しかし、データをどのように掘り下げても、それが常に理にかなっていて、合理的で自己矛盾のない全体であることを確認することを意味する場合、それらのルールを適用するためのチェックは DB で行われます。データを DB にプッシュし、そこにあるデータを操作するには、常に多くの方法があります。これらすべての方法に「ビジネスロジック」が組み込まれているわけではありません。たとえば、午前 3 時のサポート コールで DOS ウィンドウを介して DB への SQL セッションが非常に寛大であることがわかります。すべてのデータ変更が理にかなっていることを確認するロジックがDBにない場合、時間の経過とともにデータが非常にめちゃくちゃになることは間違いありません。
CRUDが複数の場所で発生している可能性があるため、いくつかの機会にsprocsに「ロジック」を入れました。「ロジック」とは、実際にはビジネスロジックではなく、「整合性ロジック」であると言わざるを得ません。それは同じかもしれません-何かが特定の方法で削除または更新された場合、何らかのクリーンアップが必要になる場合があり、その削除または更新が異なるコードベースの複数のツールから発生する可能性がある場合、それらをprocに配置することは理にかなっていますすべて使用。
さらに、「ビジネス ロジック ライン」がかなりぼやけている場合もあります。レポートを例にとると、スキーマがビジネスにとって何を意味するかについて「スマート」をカプセル化するストアド プロシージャまたはビューに依存している場合があります。列の値やその他の基準に基づいて「処理を行う」CASE ステートメントなどをどのくらいの頻度で見たことがありますか? ビジネスロジックとして解釈できますが、最適化できるDBに属している可能性があります。
多くの場合、変更を加えて展開する方が高速になるため、ビジネス ロジックはデータベース レイヤーにあります。多くの場合、最善の意図はそこにロジックを配置しないことだと思いますが、展開が容易なため、最終的にはそこに配置されます。
ビジネス ロジックをデータベースに配置する正当な理由は次の 2 つです。
私は、州によって特定の規則が適用される金融系の会社で働いています。これらの規則とその計算は、毎週ではないにしても、ほぼ毎日変更される可能性があります。その場合、計算を処理するロジックの一部をデータベースに移動する方が理にかなっています。アプリケーションを再コンパイルして再配布することなく、変更をテストして適用できますが、ビジネスを中断せずに毎日行うことは不可能です。ストアド プロシージャはテスト、承認、適用されますが、エンド ユーザーは賢明ではありません。Web ベースのアプリケーションへの移行により、ロジックをデータベースに移行することへの依存度は低下しますが、依然として存在しています。Web アプリでさえ (言語によっては) コンパイルしてサイトに公開する必要があり、ダウンタイムが発生する可能性があります。
データベースを使用して作業を行う主な理由は、単一の制御ポイントがあることです。多くの場合、アプリ開発者は、アプリケーションのさまざまな部分でコード フラグメントを再利用または書き直します。これらすべてがまったく同じように機能すると仮定しても (これは疑わしい)、ビジネス ロジックが変更された場合、アプリを見直し、再コーディングし、再コンパイルする必要があります。パラメータが変更されない限り、ビジネス ロジックがデータベースにのみ格納されている場合、これは必要ありません。
私の好みは、単純にメンテナンスの目的で、複雑なビジネス ロジックをデータベースから除外することです。午前 2 時に電話がかかってきた場合、データベース スクリプトをステップ実行するよりも、アプリケーション コードをデバッグしたいと思います。
ビジネス ロジックが遅すぎてアプリ レイヤーで実行できない場合があります。これは、クライアントの電力と帯域幅がより制限されていた古いシステムで特に当てはまります。
過去にストアド プロシージャに BL を配置した主な理由は、データベースでのトランザクションがより簡単だったからです。
アプリの展開が難しく、アプリ サーバーがない場合は、ストアド プロシージャで BL を変更することが、変更を展開する最も効果的な方法です。
特に、私が取り組んでいる（バンキング）ビジネスロジックが巨大な古いアプリケーションの場合、これらすべてのビジネスロジックをアプリケーション層で実行することはほぼ不可能であり、これらのロジックをアプリケーション層に配置すると、パフォーマンスに大きな打撃を与えます。データベースへのフェッチの数が多い場合、より多くのリソース使用率（Javaレイヤーで実行される場合はより多くのJavaオブジェクト）とネットワークの問題が発生し、abtのパフォーマンスを忘れます。
私はかなり大規模な金融システムを構築および維持するチームに所属していますが、何十万ものレコードに影響を与えたり制約を取得したりするアクションのためにロジックをアプリケーション層に入れる方法がわかりません。
パフォーマンスの問題に加えて、エラーが発生した場合、ストアド プロシージャの修正は、アプリケーションのデバッグ、修正、再コンパイル、コードの再デプロイよりもはるかに高速であり、ダウンタイムが長くなります。