変更ログ/監査データベーステーブルの最適な設計ですか？
さまざまな変更ログ/監査（何かが追加、削除、変更されたときなど）を保存するデータベーステーブルを作成する必要があります。特に詳細な情報を保存する必要はないので、次のように考えていました。
- id（イベント用）
- それをトリガーしたユーザー
- イベント名
- イベントの説明
- イベントのタイムスタンプ
ここに何かが足りませんか？明らかに、デザインを改善し続けることはできますが、複雑にすることは考えていません（イベントタイプやそのようなもののために他のテーブルを作成することは、私のニーズにとって複雑なため、問題外です）。
私が取り組んでいるプロジェクトでは、監査ログは、あなたが説明したような非常に最小限の設計からも始まりました。
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
それが、監査ログの設計が本当に安定したときです（数年前）。
もちろん、最後の「改善」は、代理キーを持つテーブルに対してのみ機能します。しかし、何だと思いますか？監査に値するすべてのテーブルには、このようなキーがあります！
テーブル/列名、更新が行われたコンピューター/アプリケーションなど、監査する必要のあるものがいくつかあります。
現在、これは実際にどの程度詳細な監査が必要か、そしてどのレベルかによって異なります。
私たちは独自のトリガーベースの監査ソリューションの構築を開始しました。すべてを監査し、手元に回復オプションも必要でした。これは非常に複雑であることが判明したため、トリガーベースのサードパーティツール ApexSQL Audit をリバースエンジニアリングして、独自のカスタムソリューションを作成しました。
ヒント：
前後の値を含める
主キーを格納するための3〜4列を含める（複合キーの場合）
ロバートが既に提案したように、メインデータベースの外部にデータを保存する
レポートの準備にかなりの時間を費やします。特に、回復に必要な場合があります
ホスト/アプリケーション名の保存を計画します-これは不審なアクティビティを追跡するのに非常に役立つかもしれません
また、古い値と新しい値、それらの元の列、および監査対象のテーブルのプライマリキーを監査詳細テーブルに記録します。監査テーブルが必要なものを考えますか？誰がいついつ変更したかだけでなく、悪い変更が発生したときに、データを元に戻す迅速な方法が必要です。
設計中に、データを回復するコードを作成する必要があります。あなたが回復する必要があるとき、それは通常急いで、すでに準備されていることが最善です。
ここと同様の質問には興味深い答えがたくさんあります。個人的な経験から追加できるものは次のとおりです。
監査テーブルを別のデータベースに配置します。理想的には、元のデータから分離する必要があります。データベースを復元する必要がある場合、実際には監査証跡を復元する必要はありません。
可能な限り非正規化します。テーブルに元のデータへの依存関係をできるだけ少なくしたい場合。監査テーブルは、データを取得するためにシンプルで非常に高速でなければなりません。データを取得するために、他のテーブルを横切って結合したり検索したりする必要はありません。
テーブルにあるもの：-
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は主キーです。監視対象フィールドが変更されるたびに現在のレコードをログテーブルに挿入するトリガーをソーステーブルに作成します。
これで、すべての変更とその変更者の記録が得られました。
一般に、カスタム監査（さまざまなテーブルの作成）は悪いオプションです。データベース/テーブルトリガーを無効にして、一部のログアクティビティをスキップできます。カスタム監査テーブルは改ざんされる可能性があります。アプリケーションがダウンする例外が発生する可能性があります。堅牢なソリューションの設計の難しさは言うまでもありません。これまでのところ、私はこの議論で非常に単純なケースを見ています。現在のデータベースおよび特権ユーザー（DBA、開発者）から完全に分離する必要があります。すべての主流のRDBMSは、DBAでさえ無効にできず、機密性を改ざんできない監査機能を提供します。したがって、RDBMSベンダーが提供する監査機能を最初のオプションにする必要があります。他のオプションは、サードパーティのトランザクションログリーダーまたはカスタムログリーダーで、分解された情報をメッセージングシステムにプッシュします。メッセージングシステムは、何らかの形式の監査データウェアハウスまたはリアルタイムイベントハンドラーになります。要約すると、ソリューションアーキテクト/「ハンズオンデータアーキテクト」は、要件に基づいてそのようなシステムを決定する必要があります。通常、開発者にソリューションを提供するには、あまりにも深刻な問題です。
分離の原理によると：
監査データテーブルは、メインデータベースとは別にする必要があります。監査データベースには多くの履歴データが含まれる可能性があるため、メモリ使用率の観点から、監査データベースを個別に保持することは理にかなっています。
データベース全体を監査するためにトリガーを使用しないでください。サポートするさまざまなデータベースが混乱することになります。 DB2、SQLServer、Mysqlなどのために1つ書く必要があります。
パーティーに遅れましたが、 AutoAuditプロジェクト を強くお勧めします。
100％無料のオープンソースです。 SQL MVPのPaul NielsenとJohn Sigouinによって作成されました。非常に安定しており、現在バージョン3.30です。
インストールが簡単。 SPを実行します。監査スキーマ、いくつかの保守SP、および監査の実行に必要なトリガーを作成します。そこから、監査するテーブルを選択します。どのような詳細。