編集時に特定のレコードで変更された複数の値を追跡するために、履歴テーブルを設計する必要があります。
例:
ユーザーには、レコードを編集するためのページが表示されます。
役職: Mr.
名前: ジョー電話:
555-1234 生年月日
: 1900-10-10
ユーザーがこれらの値のいずれかを変更した場合、古い値を追跡し、新しい値を記録する必要があります。
私は次のようなテーブルを使用することを考えました：
沿革
---------------
ID
modifiedUser
modifiedDate
tableName
recordId
oldValue
newValue
これに関する 1 つの問題は、編集ごとに複数のエントリが作成されることです。それらをグループ化する別のテーブルを用意することを考えていましたが、それでも同じ問題があります。
行のコピーを履歴テーブルに保持することも考えていましたが、それも効率的ではないようです。
何か案は？
ありがとう！
履歴を追跡するテーブルごとに、同じ形式の 2 つ目のテーブル (tblCustomer と tblCustomer_History) と日付列を作成することをお勧めします。
編集が行われるたびに、日付/時刻とともに古いレコードを履歴テーブルに挿入します。これは非常に簡単に実行でき、コードの変更はほとんど必要ありません (通常はトリガーのみ)。
これには、「実際の」テーブルを可能な限り小さく保つという利点がありますが、行われたすべての変更の完全な履歴が得られます。
ただし、最終的には、このデータをどのように使用したいかによって決まります。監査目的のみの場合、この方法は単純であり、追加のディスク容量とメイン システムへの影響がほとんどまたはまったくないことを除けば、欠点はほとんどありません。
関心のある効率のタイプを定義する必要があります。ストレージスペースの効率、履歴の記録に必要な作業の効率（トランザクションコスト）、または特定の方法でレコードの履歴を照会する時間の効率を得ることができます。 。
提案された履歴テーブルにテーブル名があることに気付きました。これは、複数のテーブルの履歴を記録する意図があることを意味します。これにより、すべてのテーブルがない限り、レコードの正確なコピーを履歴テーブルに保存するオプションが除外されます。追跡しているのは常に同じ構造になります。
列を個別に処理する場合、つまり、履歴レコードごとに1つの列値のみを記録する場合は、発生するすべての列値を正確に表すことができるポリモーフィックデータ型を考案する必要があります。
ストレージスペースの効率が主な関心事である場合、私は履歴を複数のテーブルに分割します。これは、新しい列値テーブルが編集イベントテーブルと列定義テーブルの両方にリンクされていることを意味します。編集イベントテーブルはユーザーとタイムスタンプを記録し、列定義テーブルはテーブル、列、およびデータ型を記録します。@njkが指摘したように、古い値を取得するために前の編集をいつでも照会できるため、古い列の値は必要ありません。このアプローチでスペースを節約できると期待される主な理由は、一般的に、ユーザーが使用可能なフィールドの小さなサブセットを編集するという想定です。
クエリの効率が主な関心事である場合は、追跡しているすべてのテーブルに履歴テーブルを設定し、各履歴テーブルにユーザーとタイムスタンプのフィールドを追加します。これは、編集のトランザクションコストの観点からも効率的である必要があります。
履歴テーブルに古い値と新しい値を記録する必要はありません。最新の値、作成者、日付を記録するだけです。user_idその後、レコードの日付に基づいて、いくつかの最新のレコードを取得できます。大量のデータを扱う場合、これは最善の方法ではない可能性があります。
ユーザー(id、user_id、日時、作成者、...)
サンプルデータ
id user_id datetime author user_title user_name user_tele ... 1 1 2012-11-05 11:05 ボブ 2 1 2012-11-07 14:54 ティム 3 1 2012-11-12 10:18 ボブ