さまざまな変更ログ/監査 (何かが追加、削除、変更されたときなど) を保存するデータベース テーブルを作成する必要があります。特に詳細な情報を保存する必要はないので、次のようなことを考えていました。
ここで何か不足していますか？もちろん、複雑にするつもりはありませんが、デザインを改善し続けることはできます (イベントの種類やそのようなもののために他のテーブルを作成することは、私のニーズを複雑にするため、問題外です)。
私が取り組んでいるプロジェクトでは、監査ログも、あなたが説明したような非常にミニマルなデザインから始まりました。
event ID
event date/time
event type
user ID
description
考え方は同じでした。物事をシンプルに保つことです。
しかし、このミニマルなデザインでは不十分であることがすぐに明らかになりました。典型的な監査は、次のような質問に要約されていました。
Who the heck created/updated/deleted a record
with ID=X in the table Foo and when?
したがって、（SQLを使用して）このような質問にすばやく回答できるようにするために、監査テーブルに2つの追加の列を追加することになりました。
object type (or table name)
object ID
そのとき、監査ログの設計は本当に安定しました（ここ数年）。
もちろん、最後の「改善」は、代理キーを持つテーブルに対してのみ機能します。しかし、何を推測しますか？監査する価値のあるすべてのテーブルには、そのようなキーがあります。
また、古い値と新しい値、それらの元の列、および監査詳細テーブルで監査されているテーブルの主キーも記録します。監査テーブルが必要な理由を考えてみてください。誰がいつ変更を行ったかを知りたいだけでなく、悪い変更が発生したときに、データを元に戻すための迅速な方法が必要です。
設計中に、データを回復するためのコードを作成する必要があります。回復する必要があるときは、たいてい急いでいるので、準備をしておくのが最善です。
ここと同様の質問には、興味深い回答がたくさんあります。個人的な経験から追加できる唯一のことは次のとおりです。
監査テーブルを別のデータベースに配置します。理想的には、元のデータから分離する必要があります。データベースを復元する必要がある場合、監査証跡を復元する必要はありません。
合理的に可能な限り非正規化します。元のデータに対するテーブルの依存関係をできるだけ少なくする必要があります。監査テーブルは、データを取得するためにシンプルで超高速である必要があります。データを取得するために、他のテーブルをまたいで複雑な結合や検索を行う必要はありません。
私たちのテーブルにあるもの:-
Primary Key
Event type (e.g. "UPDATED", "APPROVED")
Description ("Frisbar was added to blong")
User Id
User Id of second authoriser
Amount
Date/time
Generic Id
Table Name
汎用 ID は更新されたテーブル内の行を指し、テーブル名は文字列としてのそのテーブルの名前です。優れた DB 設計ではありませんが、非常に便利です。すべてのテーブルには単一の代理キー列があるため、これはうまく機能します。
これを行うには多くの方法があります。私のお気に入りの方法は次のとおりです。
ソース テーブル (ログに記録するテーブル) にフィールドを追加しmod_userます。
log_datetimeログに記録するフィールドとフィールドを含むログ テーブルを作成しますseq_num。 seq_num主キーです。
監視対象のフィールドが変更されるたびに現在のレコードをログ テーブルに挿入するトリガーをソース テーブルに作成します。
これで、すべての変更とその変更者の記録ができました。
分離の原則によると：
監査データ テーブルは、メイン データベースから分離する必要があります。監査データベースには多くの履歴データが含まれる可能性があるため、メモリ使用率の観点から、それらを分離しておくことは理にかなっています。
データベース全体を監査するためにトリガーを使用しないでください。サポートするさまざまなデータベースが混乱することになります。DB2、SQLServer、Mysql など用に作成する必要があります。