私はいくつかの金融ソフトウェアを作成しています。このようなソフトウェアでは、フィールドの現在の値を知るだけでなく、フィールドの値が以前に何で、誰がいつ変更を加えたかを知ることが不可欠です。これにより、履歴に戻って、たとえば誰がコミットしたかを確認できます。犯罪。
私の質問は、そのようなデザインを作成するためのベストプラクティスは何ですか？私が使用しているDBMSはPostgreSQLです。もちろん、ほとんどアクセスされるのは各フィールドの現在の値になります。また、値の変更のみを記録する必要があるため、スナップショットバックアップを作成することはこれを行うための適切な方法とは思えません。
「日記」や「取引履歴」を検索してみましたが、結果が出ませんでした。
Martin Fowlerは、彼の著書「Analysis Patterns」で金融取引システムの設計について説明しています。これは、データベース設計よりもオブジェクト指向設計に関するものですが、読む価値があります。
従来の方法は、次の行に沿って「元帳」を表すテーブルを作成することです。
transactionID | AccountID | TransactionDate | TransactionValue | OtherData...
-------------------------------------------------------------------
任意の時点での残高は、その日付までの「TransactionValue」の合計です。
そのようなテーブルは非常に大きくなる傾向があるのは事実ですが、Postgresのようなデータベースは大きなデータセットの管理に非常に効果的です。実際には、優れたインデックススキームに依存できる限り、最新のハードウェアで数千万から数億のレコードを簡単に管理できます。
パフォーマンスの制限に遭遇した場合、一般的な解決策は要約エントリを作成することです。つまり、特定の日付までのすべてのレコードをアーカイブテーブルに移動し、その日付の要約レコードを挿入します。データ量に応じて、これを10年、1年、1か月、さらには1週間ごとに行う場合があります。