3

最近、テーブルを監査する方法のトピックが私たちの議論で浮上しました...これにアプローチする最良の方法についてのあなたの意見が好きです. 以前の各 DBA が正しいと信じていたことを実行したため、データベースには両方のアプローチが混在しています (これは良くありません)。したがって、いずれかのモデルに従うように変更する必要があります。

CREATE TABLE dbo.Sample(
Name VARCHAR(20),
...
...
Created_By VARCHAR(20),
Created_On DATETIME,
Modified_By VARCHAR(20),
Modified_On DATETIME
)

CREATE TABLE dbo.Audit_Sample(
Name VARCHAR(20),
...
...
Created_By VARCHAR(20),
Created_On DATETIME,
Modified_By VARCHAR(20),
Modified_On DATETIME
Audit_Type VARCHAR(1)  NOT NULL
Audited_Created_On DATETIME
Audit_Created_By VARCHAR(50)
)

アプローチ 1:監査テーブルに、メイン テーブルから置き換え/削除されたレコードのみを格納します (システム テーブル DELETED を使用)。したがって、メイン テーブルの各 UPDATE および DELETE について、置き換えられるレコードは、'U' ( UPDATE の場合) または 'D' (DELETE の場合) として 'Audit_Type' 列を使用して監査テーブルに挿入されます。

INSERT は監査されません。レコードの現在のバージョンについては、常にメイン テーブルをクエリします。履歴については、監査テーブルにクエリを実行します。

長所: 以前のバージョンのレコードを保存するのは直感的です 短所: 特定のレコードの履歴を知る必要がある場合は、監査テーブルをメイン テーブルと結合する必要があります。

アプローチ 2:メイン テーブルに入るすべてのレコードを監査テーブルに格納します (システム テーブル INSERTED を使用)。

メインテーブルに INSERTED/UPDATED/DELETED された各レコードは、監査テーブルにも格納されます。したがって、新しいレコードを挿入すると、監査テーブルにも挿入されます。更新されると、(INSERTED からの) 新しいバージョンのテーブルが Audit テーブルに格納されます。削除すると、古いバージョン (DELETED から) のテーブルが監査テーブルに格納されます。

長所: 特定のレコードの履歴を知る必要がある場合、すべてが 1 か所にあります。

すべてをここに挙げたわけではありませんが、それぞれのアプローチには長所と短所があります。

4

2 に答える 2

4

私は一緒に行きます：

アプローチ 2:メイン テーブルに入るすべてのレコードを監査テーブルに格納します (システム テーブル INSERTED を使用)。

アイテムごとにもう1行追加すると、DBが本当に殺されますか? このようにして、完全な履歴を一緒に取得できます。

行 (すべて X 日より古い範囲) を削除しても、何かが変更されたかどうかを確認できます。

  • 監査行が存在する (パージされていない) 場合、問題の行が変更されたかどうかを確認できます。
  • 項目の監査行が存在しない場合 (すべてパージされた) 何も変更されていない (完全に新しい項目を含む変更が監査テーブルに書き込まれるため)

アプローチ 1: を使用して範囲を消去すると、新しい挿入とすべての行が消去された挿入を区別するのが難しくなります (消去日を覚えておく必要があります)。

于 2009-09-25T17:44:49.673 に答える
0

私たちがよく使用する 3 番目のアプローチは、関心のある列のみを監査し、各行に「新しい」値と「古い」値の両方を保存することです。

したがって、「name」列がある場合、監査テーブルには「name_old」と「name_new」が含まれます。

INSERTトリガーでは、「name_old」は好みに応じて空白/nullに設定され、「name_new」はINSERTEDから設定されます。UPDATE トリガーでは、DELETED から「name_old」が設定され、INSERTED から「name_new」が設定されます。DELETE トリガーでは、DELETED から「name_old」が設定され、「new_name」が空白/null に設定されます。

(または、すべてのケースで FULL 結合と 1 つのトリガーを使用します)

VARCHAR フィールドの場合、これはあまり良いアイデアとは思えないかもしれませんが、INTEGER、DATETIME などの場合、更新の違いが非常に簡単にわかるという利点があります。

つまり、実際のテーブルに数量フィールドがあり、それを 5 から 7 に更新すると、監査テーブルに次のようになります。

quantity_old  quantity_new
           5             7

特定の時間に数量が 2 増加したことは簡単に計算できます。

監査テーブルに別々の行がある場合、1 つの行を「次の」行と結合して差を計算する必要があります。これは場合によっては注意が必要です...

于 2009-09-25T17:29:15.053 に答える