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

StackOverflow https://stackoverflow.com/questions/201527

  •  03-07-2019
  •  | 
  •  

質問

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

  • 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をリバースエンジニアリングすることになりました。監査して独自のカスタムソリューションを作成します。

ヒント：

  • 前/後の値を含める

  • 主キーを格納するための3〜4列を含める（複合キーの場合）

  • すでにロバートが提案したように、メインデータベースの外部にデータを保存します

  • レポートの準備にかなりの時間を費やします＆＃8211;特に回復に必要なもの

  • ホスト/アプリケーション名の保存計画＆＃8211;これは、疑わしいアクティビティの追跡に非常に役立つ場合があります

また、古い値と新しい値、およびそれらの元の列と、監査されるテーブルのプライマリキーを監査詳細テーブルに記録します。監査テーブルが必要なものを考えますか？誰がいついつ変更したかを知りたいだけでなく、悪い変更が発生したときに、データを元に戻す迅速な方法が必要です。

設計中は、データを回復するコードを作成する必要があります。回復する必要がある場合、通常は急いでいるので、すでに準備しておくのが最善です。

ここと同様の質問には興味深い答えがたくさんあります。個人的な経験から追加できるものは次のとおりです。

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

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

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

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

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

これで、すべての変更とその変更者の記録が得られました。

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

分離の原理に従って：

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

  2. データベース全体を監査するためにトリガーを使用しないでください。サポートするデータベースが膨大になるためです。 DB2、SQLServer、Mysqlなどのために1つ書く必要があります。

パーティーに遅れていますが、 AutoAuditプロジェクトをお勧めします。
100％無料でオープンソースです。 SQL MVPのPaul NielsenとJohn Sigouinによって作成されています。非常に安定しており、現在バージョン3.30です。

インストールが簡単。彼らが提供するSPを実行するだけです。監査スキーマ、いくつかのメンテナンスSP、および監査の実行に必要なトリガーを作成します。そこから、監査するテーブルと詳細を選択するだけです。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top