ビジネスロジック：データベースとコード
私はシステムエンジニアリングの学生であり、すべての教師や友人（実際にこの分野で働いている）は、データベース（クエリ、ビュー、トリガー、 T-SQL など）。コードに入れたほうがいいと思います。
その理由は次のとおりです。
言語を変更する必要がある場合、ほとんどすべてのロジックがデータベースに含まれます。したがって、実装の時間が最小限になります。
言語の変更は、データベースよりも一般的です。
私の理由は：
（少なくとも私の国の現在の環境では）プロジェクトの言語が「簡単に」変更されないことは明らかです。 （ FoxPro にまだ残っているプログラムを見たことがあります。機能する場合、変更する必要がないためです）。
プログラミング言語は機能に関するものであり、データベースはデータに関するものです。データベースでプログラミング機能を使用できますが、データに影響を与えるコンポーネントに限定する必要があると思います。
新しい要件を実装する方が簡単です（たとえば、顧客がAPIを必要とする場合）。
通常、データベースでロジックを使用する場合、コードに実装されている残りのロジックはスパゲッティのようになります（ランダム関数など）。
一般に、データベース管理者（DBA）よりも多くのプログラマーがいるのが一般的です。
どの実装が最適ですか？
以前の説明については、 データベースに実装するビジネスロジックの量は？ を参照してください。
一般的に、誰もが自分が管理するレイヤーでの作業を望んでいます。それから彼らはそれを制御します。
すべてのデータベースベンダーは、できるだけ多くのロジックをデータベースに組み込むことを望んでいます。それはあなたをデータベースにロックするからです。その理由は、複数のアプリケーションが同じデータベースを使用する場合、コードを再利用することです。
ただし、プログラマーは強く反対します。データベースは貧弱なプログラミングオプションを提供します。コードをデータベースにデプロイするのは難しいです。データベースには、リビジョン管理、インタラクティブな編集、配備、ユニットテストのための基本的なツールがありません。ストアドプロシージャは、距離を置いてアクションをデバッグするのは恐ろしいものになる傾向があります。複数のアプリケーションが同じデータベースにアクセスすることはあまり一般的ではなくなりました。そして、何か規模を拡大する必要がある場合、最も修正が難しいボトルネックはデータベースです。
私の偏見は明らかです。私はプログラマーです。
しかし、私は20年近くプログラミングしており、そのほとんどはデータを担当するバックエンドプログラマーです。ロジックをデータベースに移動することについての議論を何度も目にしました。私はそれを実行するシステムとそれを回避するシステムを見てきました。データベースの移行、コードベースの移行などをしなければなりませんでした。
最悪の混乱は、ビジネスロジックがデータベース内にあったときに常に発生していました。それらは常に修正するのが最も難しいものでした。 「パフォーマンスのためにロジックをデータベースに移動した」という主張に何度も遭遇しましたが、クリーンな正規化データモデル、優れたインデックス、データベースの前のキャッシュレイヤーを使用すると、ほとんどの場合パフォーマンスが向上します。現代のプログラミング言語で実装された正気なアルゴリズム。
可能な限り、ビジネスロジックはデータベースレイヤーではなくソフトウェアレイヤーに保持する必要があると私は強く確信しています。 可能な限りはalwaysにはるかに及ばないことに注意してください。
どちらの方法にも強い議論があり、常に適切な選択を決定する前に、各プロジェクトにどの程度の重みを適用する必要があるかを決定するために、常にエンジニアリングの良い判断を使用します。
（他の人がコメントで提案を行うので、リストに追加できます）
ビジネスロジックを処理するデータベースの引数：
- ビジネスロジックを操作するにはデータが必要です。ロジック処理をデータに近づけると、パフォーマンスが向上します
- アップデートを適用する1つの場所
ビジネスロジックを処理するソフトウェアレイヤーの引数：
- 適切に作成されたソフトウェアは、通常、SQLストアドプロシージャよりも理解、デバッグ、保守がはるかに簡単です。
- アプリケーションサーバーは、インターネットアプリケーションが普及した場合、スケールアウトだけでなくスケールアップもできます。
熟練したプロの開発者として、アプリケーションのレイテンシを改善するための迅速な修正が必要な場合、選択は、実行速度の遅いビジネスロジックをデータベースのストアドプロシージャに移動するand/orを実行して、遅いプロセスのキャッシュを実装することができます。
ただし、データベースベースのビジネスロジックには深刻な問題があります。アプリケーションを大規模に拡張する必要がある場合は、常にスケールアウトできるシステム/プロセスを優先してください（つまり、処理プールにサーバーを追加できます）。 SQLデータベースはスケールアップのみが可能です（既存のサーバーを置き換えるには、より強力なサーバーを見つける必要があります）。アプリケーションに多数のデータベースビジネスロジックがある場合は、この問題に早く到達します。
プロデータベースの引数に2つの非常に重要なポイントがありません：
- パフォーマンス：データへの直接アクセスでデータベースコードが実行されるため、不要な転送が回避されます（同じマシン上のAPIの取得とマッピングスキーム全体での転送、またはクライアント/サーバー通信用のネットワーク全体）
- consistency：複数のアプリケーションが同じデータベースにアクセス/更新する可能性があるため、一貫性とビジネスルールをその中に集中的にカプセル化することで、確実に適用されます。
しかし、いくつかの非常に重要な点が、コントラデータベースの引数にもありません。
スケーラビリティ：データベースに追加する量が多いほど、このコンポーネントはボトルネックになります。もちろん、より大きなサーバーを使用してCPUを追加することもできますが、遅かれ早かれ、物理的な制限を満たします。
ベンダーロックイン：SQLは非常に標準化されていますが、トリガーとプロシージャの言語はかなり多様化しており、多くの場合独自仕様です： T-SQL Microsoftの場合 PL/SQL Oracleの場合 任意の言語 DB2の場合。データベースを開発すると、ベンダーに縛られ、競争の激化を利用したり、新しいオペレーティング環境に移行したりできなくなります。
レガシーアーキテクチャ：データの集中化と巨大サーバーでの処理...これはメインフレームの時代に私たちを連れ戻しませんか？これは、時代遅れであるように思われ、最大のスケーラビリティを目指して新しい主要なアーキテクチャのトレンドが出現すると、柔軟な NoSQL データベース 異なるタイプ オブジェクト指向の開発に理想的に適合 microservices =すべてのマイクロサービスが独自のデータベースを持ち、ビッグデータアーキテクチャ（ lambdaアーキテクチャ）など すべての処理パイプラインはデータベースの外部にあります。
廃止された引数：エラーが発生しやすく、アプリケーション間でコピーされた冗長なcobolコードが終了しました。昨日RDBMSに確実にカプセル化できたものは、保守可能で再利用可能なオブジェクト指向コンポーネント、ライブラリ、バージョン管理システムを使用して、最新のソフトウェアアーキテクチャに非常にうまくカプセル化できます。
要約する：
- はい、データベース側に最大限のロジックを配置するための有効な引数があります。しかし、これらの議論は、インターネットの規模、技術の変化、ビッグデータの出現といった新たなニーズや制約を満たしていません。
- いいえ、私は普遍的な最善のアプローチがあるとは思いません。最も適切なアプローチは、具体的な要件とニーズに基づいて、ケースバイケースでソフトウェアアーキテクトが選択するものとします。
すでに指摘されているすべての事実に加えて、データベースが最終的に安くなることが判明するのではなく、コードにビジネスロジックを含めることも忘れないでください。
[〜＃〜] php [〜＃〜] で記述されたアプリケーションの開発者を探し、データベースとして MySQL を使用する場合、ビジネスロジックがデータベース、単純なPHPプログラマでは不十分であり、ストアドプロシージャの記述、デバッグ、最適化の方法も知っている人を見つける必要があります。突然、1つだけではないことを知っている人が必要になります、PHP、ただし2つPHPおよびMySQLプログラミング。
PostgreSQL のようなより高性能なエンジンに移行することさえ考えないでください。そうすれば、すべてのストアドプロシージャを PL/SQL に変換する人を雇う必要もあります。
コードにビジネスロジックがある場合、これはPostgreSQLの新しい抽象化レイヤーを作成し、アプリケーションの依存関係を入れ替えるだけの問題です、ブーム、アプリケーションは突然PostgreSQLを認識します。
以前の回答は、ロジックをアプリケーションコードとデータベースのどちらに配置する方が簡単/良いかについての大きな理由を示しています。私が強調したい1つの例外は、ビッグデータデータベース/技術スタックを使用する場合です。この場合、欠点の多くはなくなります。
- 単体テストは、データベースに配置するのは、作成した実際のコードであるため、作成できます。
- 単体テストではありますが、デバッグできます。
- コードなので、バージョン管理ができます。
そして、データベースにロジックを持つことの利点は、さらに重要になります。
- 処理されるデータの量によっては、アプリケーションコードにデータを送るのが不合理になる場合があります。
- スケーリング-コードはデータベースのスケーリングと同じようにスケーリングします。多くの場合、パフォーマンスとストレージはノード（マシン）の数に比例します。
すばらしい質問です。これは、私がオフィスで定期的に主張していることです。
私の見解では、ほとんどのロジックはコード内にあるべきです。それぞれに長所があるため、さまざまな言語を使用することは常に非常に魅力的ですが、完璧な開発設定（非常にまれ）がない限り、1つの言語を使用することをお勧めします。
人々はユニットテスト/リビジョン管理のバージョン管理に言及しましたが、非常に重要なことは配備です。データベースのコードの変更をコードの変更と同期させる必要があると危険な場合があります。
大規模なソフトウェア開発会社に所属している場合は、どちらかの側（データベースプログラミングかコーディングか）を知っている専門家が十分にいるかもしれませんが、それ以外の場合は、2つの世界（最も重要なのは、ロジックのどの部分がどの言語である必要があるかを決定する際に、適切なトレードオフを行います）。
個人的には、SQLプログラミング言語は非常に原始的で、それらの開発ツールはさらに悪いと思います。だから私は現代のプログラミング言語を支持します。優れたORMは、ほとんどの開発者がデータベースについて何も知る必要がないので、投資する価値があります。人々はサーバー側で物事を行うことの効率に言及し、これは放棄されるべきではありません。クライアント側のAPIのように見えるもの（C＃のIQueryableなど）を使用してサーバー側の操作を表現できる、非常に優れたプログラミングパターンがいくつかあります。
実際には、私はまだ奇妙なビューまたはストアドプロシージャを使用していますが、それらは通常、純粋に集約のためのものであり、「ビジネス」ロジックが含まれていません。これは、たとえばExcelピボットテーブルのソースとして使用できるため、非常に便利です。