sql - SQLに監査テーブルの主キーを含める必要がありますか？

Question

メインテーブルのレコードに対して行われた変更を追跡するための監査テーブルを作成しています。

ここで、監査テーブルはメインテーブル（たとえば従業員テーブル）の正確な複製ですが、メインテーブルで発生するすべての変更に対して「挿入」のみがあります。したがって、重複（同じEmployeeID）があるので、エントリごとに個別のAudit_IDを追加する必要がありますか？

Answer 1

確かに、テーブルにはある種の主キーが必要です。

重複がある場合は、重複を削除し、「挿入の理由」（デバッグ目的）を追跡する方が簡単です。

一部RDBMSの（のようMySQLにInnoDB）は、明示的に行わなかった場合に実際に非表示の主キーを作成するため、自分で作成し、表示されて使用できる場合は作成します。

Answer 2

Employeeの EmployeeID は一意ですが (更新は新しい行を追加せず、既存の行を変更するだけです)、監査テーブルには同じ EmployeeId を持つ複数の行 (最初の挿入用に 1 つ、その従業員の後続の更新ごとに 1 つ)。

また、Employee のエンティティは従業員です。ただし、監査のエンティティは監査レコードです。彼らは自分のIDを持つべきです。

何か問題が発生し、実際に監査レコードを更新または削除する必要がある場合に、これが必要になります。実際、従業員が挿入された場合、1 つの列の値が更新され、次に元の値になるように再度更新されます。監査には 2 つの同一のレコードがあります。一緒に削除または更新する必要があります（更新または削除で制限句を使用しない限り）。

これは、監査テーブルにもタイムスタンプを追加することの有用性を示しています。ただし、それとemployeeidを複合キーとして使用する必要があるとは思わないでください。まず、複合キーが最悪です。第 2 に、タイムスタンプの粒度が、システムが 2 回の更新 (バッチ操作などで同じ従業員の 2 回の更新) を実行するのにかかる時間よりも短い可能性は十分にあります。(Sybase の datetime には 3 ミリ秒の粒度があります。Intel Core 2 Extreme は、その時間で約 2億の命令を実行できます。)

Answer 3

従業員IDと監査日時を複合キーとして使用できます...

Answer 4

はい。すべてのテーブルの非セマンティック主キーは、実用的な方法で参照できるため、ベストプラクティスであると思います。日付を使用するよりもはるかに簡単に「から」audit-idへの変更を視覚化できます。audit-id+1