データベースにコードを配置するか、アプリケーションにコードを配置するかをどのように決定しますか？
議論のために：
- 私たちが構築しているアプリケーションが償却スケジュールであると仮定しましょう。
- また、データベースにtblAmortizationPaymentsというテーブルがあり、毎月の支払いに関する情報を別々の行に格納していると仮定します。
- さらに、データベース言語が計算の実行に必要な数学計算をサポートできると仮定しましょう。
この30年の住宅ローンの償却スケジュールを作成する場合、これらの360計算を実行するためのコードをデータベース内（これはストアドプロシージャであると想定しています）またはアプリケーション内のどちらに配置するかをどのように決定しますか？
私は、あなたがこの種の決定を行うためのあなたの思考プロセス、またはそれに伴う可能性のある同様のシナリオにもっと興味があります。
ストアドプロシージャとノーストアドプロシージャの2つの考え方があります。データベースはデータを保持するためだけのものであり、プログラムはそのデータを分析して使用するためのものです。 Entity Frameworkの登場により、コード側に重点が置かれるようになりました（私の意見では）。
ストアドプロシージャを使用している場合、潜在的なバグを探す場所が2つあります。コードやストアドプロシージャです。
データベースロジックをデータベース内に保持することを常にお勧めします。その理由は、基礎となるデータストアの詳細の抽象化をアプリケーションに対して不透明にする必要があるためです。
データベース構造が変更された場合は、ストアドプロシージャ、関数、およびビューを変更する必要があります。ただし、アプリケーションがデータベースのマイナーな変更からメジャーな変更に移行することは望ましくありません。
データベースエンジンは、ストアドプロシージャを使用して、パラメータ値が変更された場合でも実行プランをキャッシュします。
ロジックの分離は可能な限り分離する必要があり、それはすべてn層アーキテクチャの一部です。
データベースロジックはデータベースに任せてください。
私の心の主な要因：
- これをプログラムする開発者は、データベースの言語またはアプリケーションの言語に習熟していますか？
- アプリケーションを実行しているサーバーと比較して、データベースサーバーの負荷はどのくらいですか？
- 現在、どちらの形式でどのくらいのコードが存在していますか？
DBサーバーが非常に頻繁に使用されているため、ストアドプロシージャの実行中にタイムアウトになる可能性がある場合は、アプリケーションで実行することをお勧めします。同様に、開発者が互いに豊富な経験を持っている場合、各オプションの利点をどのように評価したいかに応じて、弱い側でスキルを構築するか、強い側を活用するために使用できるため、理にかなっています。
データベース内にコードを配置する際の問題は、ビジネスロジックを記述したものと比較して、データベースのプログラミング言語があまり良くないことです。しばらくすると、タイプに基づいて複数のタイプの償却をサポートしたいとします。契約、および一部の契約は、LIBORなどのレートテーブルを参照するレート式の変数を使用して、個々の契約によって異なる方法で定義された式として計算された可変レートに基づいていること。ここで、複数の通貨が投入されると想像してください。一部の契約では、契約が書かれている国の休日カレンダーに基づいて、月の最初の営業日に利息を計算するとします。
明らかに、YAGNIはおそらくallの例をカバーしますが、重要な点は、ビジネスロジックをデータベースからより強力な言語に移行したくなるビジネス要件がたくさんあるということです。もちろん、YAGNIを適用してストアドプロシージャに保持することもできますが、ビジネスレイヤーで開始すると、データベースに移動するよりもビジネスレイヤーに移動する可能性が高くなります。原則。
これは難しいことかもしれませんが、特定のケースでは覚えておくべきことです。
ここには2つの競合する哲学があります。
支払いを計算するためのすべてのビジネスロジックをアプリケーションに配置する場合、それに伴うアプリケーションのニーズ（デスクトップ、Web、スマートフォン、プラットフォームの変更、Webサービス、その他のデータベースなど）では、そのコードを複製する必要があります。私たちは今、同じデータベースにアクセスし、同じことのいくつかを実行し、それでも常に合理化されたデータベースコードに依存しているわけではない2つのアプリケーションを使って仕事をしているときに苦労しています。
データベースに計算を行わせる場合は、1か所で行うだけで済みます。どのアプリケーションもデータベースに接続し、ストアドプロシージャを呼び出して、同じ結果を得ることができます。 2人の幹部が、彼らの報告が正しい数字を示していると主張したり、あるアプリが支払いを不足していることを示し、別のアプリが過払いを示しているために誰かの家が差し押さえられていると主張することは決してありません。
私の意見では、ビジネスロジックはデータベースでできる限り実行する必要がありますが、それができない場合は、1か所にのみ配置し、データベースとアプリケーションの間で分割しないようにしてください。
これに対する正しい答えはありません。
バグがある場合は、ストアドプロシージャを簡単に更新できます。プロシージャを更新するだけで、コードをビルドする必要はありません。コードでは、バグがある場合はビルドが必要になります。
バックエンドデータを変更した場合（OracleからSQl Server、またはその逆）、プラットフォームが同じであれば、コードはそのままで移植できます。コードは移植する必要があります。
コードを使用すると、拡張可能な償却スケジューラを設計する方が簡単で複雑ではありません。計算がクライアントから変更された場合、拡張性が設計目標になります。ストアドプロシージャはややモノリシックであるため、コードの方が適しています。ストアドプロシージャを使用すると、さまざまな種類の計算が必要になると、面倒になることがわかりました。
計算が何であれ同じであるとビジネスが言っている場合、私はストアドプロシージャに傾倒し、将来の違いがある可能性がある場合は、コードに入れて拡張可能にします。
最初に自問しなければならないのは、計算がデータベースに記録されるときの計算の正確さと正確さをどれだけ重視するかです。
お金や法定のプライバシー要件が厳しくなっている場合は、計算でアプリケーションを信頼することはできません。データベースが計算を実行する必要があるか、できれば、管理下のロックされた部屋で実行されるいくつかの中間ビジネスロジック層。
問題は、外部クライアントからのデータを信頼できないことです！誰かがあなたのデータベースに嘘をついてお金を稼ぐことができれば、彼らがそうする可能性は十分にあります。データベースに間違った番号を報告するだけで、1％で$ 500,000の住宅ローンを取得できるとしたら、それを実行する強い動機があります。そのようなお金のために、アプリケーションとデータベース間のトラフィックをネットワークスニッファで監視しながら、デバッガの下でアプリケーションを実行することは私の価値があるかもしれません。最終的には、アプリケーションを偽装する方法を学び、自分で選択した数をデータベースに送信します。
計算の整合性をあまり気にせず、計算について嘘をついて誰も利点を得ることができない場合は、それほど心配する必要はありません。あなたは他の人々が提供した理由に基づいて決めることができます。
編集：クライアントからの計算を信頼してはならない特定の例をいくつか追加しましょう。
セキュリティ検証。ばかげているように聞こえますが、これはWebサイトにときどき発生します。パスワードのチェックは埋め込みJavascriptで行われます。または、ユーザーはデータベースをチェックして1回検証され、検証の結果はCookieに格納されるか、URLのパラメーターとして格納されます。 URLパラメータを？isAuthenticated = "F"から？isAuthenticated = "T"に変更するだけでクラックされたWebサイトがあります。
ボーナス/手数料の計算。販売部隊が販売を入力するアプリケーションを使用していて、ボーナスが計算されているとします。データベースがアプリケーションによって送信されたボーナスまたはコミッションを単に記録する場合、技術的なバックグラウンドを持つ営業担当者はデバッガーを使用してコミッションを増やすことができます。データベースまたは中間層は、少なくとも計算の有効性をチェックする必要があります。その後、データベースとアプリケーションで計算用のコードを複製します。
計算のタイプ。あなたの例では、データベースがこのタイプのタスクで手続き型プログラムほどうまく機能しないと思います。
コードの共有コーディングの共有方法に制限がある場合があります。すべてのアプリケーションのカスタムコードを作成している場合は、再利用可能な形式を使用できます。一部のサードパーティアプリケーションや、コードとレポートライターを制御しないアプリでは、ストアドプロシージャまたは他の種類のデータベースオブジェクトを使用する必要がある場合があります。
チームメンバー間で作業を分散します。 2人のスタッフがいて、そのうちの1人がデータベースの専門分野にいない限り、コードを同じ場所に配置して一貫性を保つことは素晴らしいことです。分割するのは理にかなっています。工数を活用する作業。
ハードウェア間で作業を分散します。これは、大量のバッチプロセスが進行している場合にのみ意味があります。これにより、開発者はアプリサーバーとデータベースサーバー間でランダムなタスクの負荷を分散しようとします。どちらか一方のハードウェアを増やして、すべてのコードをそこに配置する可能性が高くなります。
開発者の専門知識開発者には、おそらく習熟度に基づく好みがあります。最も簡単だと思う場所にコードを記述します。もちろん、アプリケーションのパラメータ内で作業しようとしていますが、選択肢があれば...