かなり複雑なデータベースでデータの変更履歴を維持するために人々が成功したいくつかの戦略は何ですか. 私が頻繁に使用して開発しているアプリケーションの 1 つは、レコードが時間の経過とともにどのように変化したかを追跡するためのより包括的な方法から本当に恩恵を受ける可能性があります。たとえば、現在、レコードには多数のタイムスタンプと変更されたユーザー フィールドを含めることができますが、操作がロールバックされた場合など、複数の変更をログに記録するためのスキームは現在ありません。完璧な世界では、保存などのたびに記録を元どおりに再構築することができます.
DBに関するいくつかの情報：
使用できる戦略の 1 つは、MVCC (Multi-Value Concurrency Control) です。このスキームでは、テーブルの更新は一切行わず、挿入のみを行い、各レコードのバージョン番号を維持します。これには、任意の時点からの正確なスナップショットを提供できるという利点があり、多くのデータベースを悩ませている更新ロックの問題も完全に回避できます。
しかし、これは巨大なデータベースになり、すべてを選択するには、レコードの現在のバージョンを選択するための追加の句が必要になります。
Hibernate を使用している場合は、JBoss Enversをご覧ください。プロジェクトのホームページから：
Envers プロジェクトは、永続的な JPA クラスのバージョン管理を容易にすることを目的としています。あなたがしなければならないのは、@Versioned でバージョン付けしたい永続クラスまたはそのプロパティのいくつかに注釈を付けることだけです。バージョン管理されたエンティティごとに、エンティティに加えられた変更の履歴を保持するテーブルが作成されます。これにより、手間をかけずに履歴データを取得してクエリを実行できます。
これはエリックのアプローチにいくらか似ていますが、おそらくはるかに少ない労力です。ただし、データベースへのアクセスに使用する言語/テクノロジはわかりません。
過去に、トリガーを使用してデータベースの更新/挿入/削除ログを作成しました。
上記のアクションのいずれかが特定のテーブルで実行されるたびに、アクション、実行したデータベース ユーザー、タイムスタンプ、実行されたテーブル、および以前の値を追跡するロギング テーブルにレコードを挿入できます。
実際の削除または更新が実行される前に値をキャッシュする必要があるため、おそらくより良い答えがあると思います。ただし、これを使用してロールバックを行うことができます。
トリガーを使用する場合の唯一の問題は、挿入/更新/削除のパフォーマンスのオーバーヘッドが増えることです。スケーラビリティとパフォーマンスを向上させるには、データベーストランザクションを最小限に抑える必要があります。トリガーを介して監査すると、トランザクションの実行に必要な時間が長くなり、ボリュームによってはパフォーマンスの問題が発生する可能性があります。
もう1つの方法は、Oracleの場合のように、データベースが「Redo」ログをマイニングする方法を提供しているかどうかを調べることです。REDOログは、データベースが失敗して回復する必要がある場合にデータを再作成するために使用するものです。
トリガーと同様に (またはトリガーを使用しても)、すべてのトランザクションでロギング イベントを非同期に発生させ、別のプロセス (または単にスレッド) に実際にロギングを処理させることができます。アプリケーションに応じて、これを実装する方法はたくさんあります。最初のトランザクションで不要な負荷が発生しないように、アプリケーションでイベントを発生させることをお勧めします (これにより、監査ログのカスケードによるロックが発生することがあります)。
さらに、監査データベースを別の場所に保持することで、プライマリ データベースのパフォーマンスを向上できる場合があります。
私は PostgreSQL ではなく SQL Server を使用しているため、これがうまくいくかどうかはわかりませんが、Pop Rivett が監査証跡の作成に関する素晴らしい記事をここに掲載しています: Pop rivett の SQL Server FAQ No.5: 監査をポップするトレイル
監査テーブルを作成し、監査するテーブルごとにトリガーを作成します。
ヒント: Codesmithを使用してトリガーを作成します。