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