データベースに顧客の口座残高を格納するフィールドを用意するか、ビューとクエリを使用して情報を生成する方がよいでしょうか。
8 に答える
私が取り組んだ1つのプロジェクトでは、現在の残高を1つのフィールドに保存し、すべてのトランザクションを別のテーブルに保存しましたが、このプロジェクトがデータを100%(またはそれ以上)または時間的に完全にすることの重要性のレベルのために、残高のハッシュを別のフィールドに保存し、整合性を確保するために呼び出されるたびにハッシュを比較しました。一致しなかった場合は、トランザクションテーブルから再計算し、再ハッシュしてからカスタマーサポート部門に送信しました。レビュー用。
パフォーマンスに関しては、両方だと思います。すべてのトランザクションのログを (別のテーブルに) 保持しますが、トランザクションを追加すると更新される現在の残高を格納する顧客レコードのフィールドを維持します。
これは、残高にアクセスする頻度、必要なたびに再計算するのがどれほど複雑かなど、多くの要因に依存すると思います。ビューなどのオーバーヘッドは何ですか。
純粋にあなたが提供した情報に直面して、毎回ゼロから再計算するのは苦痛になる可能性があるため、値を保存します。
"場合によります"。ほとんどの場合、派生データは避けたいと思います。ただし、導出された合計を使用することが正当化される場合もあります。
適例:
私は信用データベース アプリケーションに取り組みました。このアプリケーションでは、残高はさまざまなもので構成されており、時間の経過とともにさまざまなビジネス ルールが使用されていました。たとえば、「残高」は実際には、元本、手数料など、さまざまなバケットからのさまざまな残高の合計でした。
トランザクションが転記されると、ビジネス ルールに従って異なるバケットに割り当てられました。手数料は手数料バケットに移動しました。購入、クレジット、およびデビットは、プリンシパル バケットに送られました。これらの割り当てとルールは、時間の経過とともに変更される可能性があります。
時間の経過とともに変化するビジネス ルールに直面して、その場で 100,000 の顧客残高をクエリすることを想像してみてください。これは、導出された値を持つことが実際に理にかなっている確固たるケースです。アカウントを「巻き戻し」、監査と検証の目的で残高を時系列に再構築するための一連のアルゴリズムを維持しましたが、大規模なセットに対してはやりたいことではありませんでした.
ビューとクエリで十分な速さで結果が得られる場合は、別のフィールドに保存しないでください。
十分に高速でない場合は、別のフィールドに保存してください。このフィールドには冗長な情報が格納されるため、同期を維持することが非常に重要です。
ここにいる全員が正しい。それは依存します。しかし、ビューを使用することで、両方の長所を活かすことができます。かなり小さなシステムを使用しているように聞こえますが、バランスを動的に計算するのが最も簡単な方法です。シンプルにするために、必要なアカウント データ (動的に計算される) を持つ単一のビューを定義します。
それ以上のパフォーマンスが必要な場合は、残高を主勘定テーブルに更新するためのトリガー ベースのシステムをセットアップし、バックグラウンドでビューを更新して、他のコードを変更する必要がないようにします。いずれかのクエリに対して適切なデータベース分離モードを使用していることを確認してください。そうしないと、問題が発生します。;-)
これは、この情報にアクセスする必要がある頻度の関数になります。たまになら、先に進んで再計算すると思います。
ビューとクエリを使用してください。実行速度に驚かれることでしょう。