0

監査目的で監査エントリを保存するために、私はどのデータが変更されたかを記録する方法に取り組んできました。

私は過去に2つの異なる方法を実行しましたが、現在新しいシステムを作成していて、どちらを使用するかを考えています。

  1. AuditEntryテーブルとAuditEntryChangeテーブルがあります。変更された各フィールド値はAuditEntryChangeテーブルに入れられ、AuditEntryへのFKがあります。

  2. 変更されたフィールドと値を単一のフィールドのAuditEntryテーブルのXMLに保存します。

上記のうち、保存とクエリのパフォーマンスが高いのはどれですか？（XMLを使用する場合のシリアル化/逆シリアル化の影響を含みます）。そして、どちらがより少ないスペースを占めるでしょうか？

また、監査テーブルにGUIDまたはint PKを使用することをお勧めしますか？それぞれの理由が思い浮かびます。

4

2 に答える 2

1

個人的には、レポートの場合、データベースに各フィールドを含める方がはるかに簡単です。

GUIDと整数は、テーブルに含めるレコードの数によって異なります。整数は4バイトを使用しますが、GUIDは16バイトです。GUIDの方がはるかに簡単ですが、サーバー間の展開を検討している場合。

これは賛否両論の良い記事です。

于 2011-06-28T19:31:43.303 に答える
1

答えは、監査テーブルのクエリをどのように計画するかによって異なります。監査テーブルについて考慮すべきことは、一般的なシナリオでは、レコードは読み取り専用であり、照会されるよりもはるかに頻繁に挿入されるということです。

私は次の理由でオプション2に傾倒します：

  • 単一の行を挿入する方が、外部キー制約のある複数の行を挿入するよりも高速です。
  • XMLフィールドがあると、データベーススキーマを気にすることなく、監査データの構造に大きな柔軟性がもたらされます。
  • SQL ServerはXPath構文を使用してXML列をクエリできるため、リレーショナルクエリ機能の一部を引き続き使用できます。
  • 結合がないため、フォームでの表示など、多くのレコードを選択することも高速です。
  • このモデルは、NoSQLストレージなしで簡単に移植できます。
  • XMLシリアル化は、コードから挿入する場合、またはコードにロードする場合にのみ関係します。SQLを介してXML列を直接クエリすることもできます。
  • スペース要件は増加すると思いますが、これはリレーショナルモデルから生じる可能性のあるインデックスのサイズによって異なります。

監査テーブルのintとGuidについては、次の理由でGuidを使用します。

  • NHibernateのようなORMを使用して挿入する場合、生成されたIDを取得するための挿入後の選択はありません。効率的にバッチで挿入できます。
  • guidは4倍大きいですが、100万レコードの場合、約10MBの違いが生じます。それは本当に問題ですか？特に、監査ログのPKによってクエリを実行する可能性が低いためです。
  • 他のデータベースまたはストレージメカニズムへの移植は簡単です。
于 2011-06-28T20:19:02.707 に答える