変更ログ/監査データベーステーブルに最適な設計ですか？[閉まっている]

さまざまな変更ログ/監査（何かが追加、削除、変更されたときなど）を格納するデータベーステーブルを作成する必要があります。特に詳細な情報を保存する必要がないので、次のように考えていました。

• 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列を含める

• Robertによって既に提案されているように、メインデータベースの外部にデータを保存する

• レポートの準備にまともな時間を費やします。特に、回復に必要となる可能性のあるレポートを準備します

• ホスト/アプリケーション名の保存を計画する-これは、不審なアクティビティを追跡するのに非常に役立つ可能性があります

ここと同様の質問には多くの興味深い答えがあります。私が個人的な経験から追加できる唯一のものは：

1. 監査テーブルを別のデータベースに配置します。理想的には、元のデータから分離する必要があります。データベースを復元する必要がある場合、実際には監査証跡を復元する必要はありません。

2. 合理的に可能な限り非正規化します。テーブルには、元のデータに対する依存関係をできるだけ少なくしたいとします。監査テーブルは、データを取得するためにシンプルかつ高速である必要があります。データにアクセスするために、他のテーブル間での複雑な結合やルックアップはありません。

テーブルにあるもの：-

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設計ではありませんが、非常に使いやすいです。すべてのテーブルに単一の代理キー列があるため、これはうまく機能します。

一般に、カスタム監査（さまざまなテーブルの作成）は不適切なオプションです。データベース/テーブルトリガーを無効にして、一部のログアクティビティをスキップできます。カスタム監査テーブルは改ざんされる可能性があります。アプリケーションをダウンさせる例外が発生する可能性があります。堅牢なソリューションの設計の難しさは言うまでもありません。これまでのところ、私はこの議論で非常に単純なケースを見ています。現在のデータベースや特権ユーザー（DBA、開発者）から完全に分離する必要があります。すべての主流のRDBMSは、DBAでさえ無効にできない、秘密を改ざんできない監査機能を提供します。したがって、RDBMSベンダーが提供する監査機能を最初のオプションにする必要があります。その他のオプションとしては、サードパーティのトランザクションログリーダーまたはカスタムログリーダーがあり、分解された情報をメッセージングシステムにプッシュして、何らかの形で監査データウェアハウスまたはリアルタイムイベントハンドラーに変換します。要約すれば：ソリューションアーキテクト/「ハンズオンデータアーキテクト」は、要件に基づいてこのようなシステムの宛先を決定する必要があります。通常、ソリューションを開発者に引き渡すだけでは、あまりに深刻です。

これを行うには多くの方法があります。私の好きな方法は：

1. mod_userソーステーブル（ログに記録するもの）にフィールドを追加します。

2. ログを記録するフィールドと、log_datetimeおよびseq_numフィールドを含むログテーブルを作成します。 seq_num主キーです。

3. 監視対象フィールドが変更されるたびに現在のレコードをログテーブルに挿入するトリガーをソーステーブルに作成します。

これで、すべての変更の記録と誰が変更したかがわかります。

分離の原則によると：

1. 監査データテーブルは、メインデータベースから分離する必要があります。監査データベースには多くの履歴データが含まれる可能性があるため、メモリ使用率の観点から、それらを分離しておくことは理にかなっています。

2. トリガーを使用してデータベース全体を監査しないでください。サポートするためにさまざまなデータベースが混乱することになります。DB2、SQLServer、Mysqlなど用に1つ作成する必要があります。