データベース履歴テーブル/追跡テーブル
現在、私はこのような追跡/履歴テーブルを構築したいと思います：
- PrimaryKey-ID
- OtherTableId-fk
- fieldName-追跡するフィールドの名前
- OldValue
- NewValue
- UserName
- CreateDateTime
したがって、基本的には、別のテーブルの履歴を追跡するテーブルを用意し、変更されたフィールドの列名を新旧の値で格納します。私の質問は、誰でもこれに穴を開けることができますか？また、追跡するテーブルの列名のみがfieldName列に入力されるようにする最も簡単な方法は何ですか？現在私の選択肢は、構築しているサービスに列挙型を含めるか、別のステータステーブルを作成して、fieldNameをfkにすることです。より良いアイデアはありますか？
編集目標：現在、追跡する必要があるフィールドは2つだけです。 1つのフィールドは履歴を表示するためにWebページに表示され、もう1つのフィールドは1つの部門のみがアクセスでき、クエリを実行できるデータベースのビューにアクセスできます。彼らは、この1つのフィールドだけをクエリして、誰がフィールドを変更し、何を変更したかに関する情報を取得します。これが、データベースフィールドがテーブルレコード履歴の正確なコピーを持つのではなく、テーブルカラムを定義する場所に設定したかった理由です。将来フィールドを追加または削除する可能性がある2つのフィールドのみを追跡する必要があります。
ありがとう！
穴をあける：データベーススキーマが後で同じ時点で変更され、列名が変更された場合、または列が完全に削除された場合はどうなりますか？多くのデータベースシステムでこれが可能です。次に、「fieldName」はどうなりますか？
データの整合性のために、すべての更新または削除操作で確実に追跡テーブルが更新されるようにする必要があります。これは、トリガーがストアード・プロシージャーを呼び出すことによって最もよく達成されます。これらのストアドプロシージャのみが追跡テーブルへの書き込みアクセス権を持っていることを確認してください。これにより、他のユーザーが間違った値を書き込むことができなくなります。
Dbベンダー固有のソリューションを使用できる場合：ほとんどのdbシステムには、スキーマ情報（テーブル名、テーブルID、列名など）が格納されるシステムテーブルがあります。このようなシステムテーブルへの外部キー参照を設定できるかどうかを確認できます。データベースがこのようなものをサポートしている場合、フィールド名をフィールドIDで置き換えることができます。
実際、特定のテーブルのすべての列（列の小さなサブセットだけでなく）を含む行全体を追跡する必要がある場合は、@ sarfeastの提案を考慮する必要があります。名前と値のペアモデルの欠点について この記事 をお読みください。
私が見た中で最も成功した変更監査（履歴追跡）の実装は、一般的ではなく、はるかに単純です。監視するテーブルごとに変更ログテーブルを作成し、同一の列名とデータ型を保持します（タイムスタンプ用の追加の列があります）。
最終目標、つまり監査済みデータをどのように処理するかは、各アプローチがどれほど適切であるかを評価するのに役立ちます。
要するに：次のテーブルにAudit Trailメカニズムを設定する必要があります値の変化を追跡したい。
単一の監査証跡テーブル：
テーブル名、フィールド名、データの古いバージョンと新しいバージョンを記録するテーブルを作成します。この方法では、通常、データの古いバージョンと新しいバージョンの両方、および変更されたフィールドのみをログに記録します。これをトリガーに実装するには、テーブルに主キーがあるか、単一の行のみが更新される必要があります。
これを達成する方法についてのスクリプトを含む良い投稿を以下に示します- Creating Audit Trails
その他の役立つ参考資料：
アイデアについては、NHibernate Envers プロジェクトドキュメント を確認してください。
基本的に、タイムスタンプやユーザーなどのデータを追加できるリビジョンテーブルが1つあります。次に、追跡する各テーブルは、すべての列が複製された追加の監査テーブル、リビジョンテーブルへのfk、およびリビジョンのタイプ（追加、変更、削除）を取得します。私の知る限り、削除を防ぐため、監査テーブルに実際のテーブルへの実際のFKを持たせたくないでしょう。