0

私は追跡する必要があります

  • CreatedByUserId
  • ModifiedByUserId
  • 作成日時
  • 変更日時

私のエンティティのほとんど。かなり標準的。

これらの列をすべてのテーブルに追加する方が良いと思いますか...または、すべての変更を追跡するために使用される既存の個別の監査テーブルを指す、監査するテーブルにCreatedAuditEntryIdとFK を配置するだけのほうがよいと思いますか?ModifiedAuditEntryId

AuditEntry は次のようになります。

  • ID
  • ユーザーID
  • 日付時刻

Created 情報と Modified 情報を取得するために 2 つの結合を行わなければならないという明らかなパフォーマンスへの影響があります...しかし、利点は、2 つの異なる場所で状態を維持していないことです。

アップデート：

明確にするために、AuditEntry テーブルには、すべてのテーブルに対するすべての変更が含まれています。ここでの問題は、そのテーブルを FK を介して作成および変更された情報に利用するかどうか、または結合を避けるために、情報が必要な各テーブルに上記の 4 つの列を追加するかどうかです。

4

2 に答える 2

1

「より良い」はあなたのニーズが何であるかに依存します。

必要なのが最後の変更イベントだけである場合は、監査列をテーブルに追加することを（リソース的に）行うことをお勧めします。更新は、その1つの行に触れるだけで済みます。

一方、誰かがレコードに触れるたびに監査レコードが必要な場合は、別の監査テーブルを用意するしかありません。

于 2011-06-29T15:56:54.963 に答える
1

私の好みは、FK関係を持つ別の監査テーブルです。それ以外の場合は、最後のエントリしか表示されず、監査にはあまり役立ちません...

これらのエントリを更新するために何を使用していますか? SQL ユーザーから UserID を暗示できる場合は、すべてトリガーで実行できます。

私はMVCで似たようなものを見ていて、システム全体のコントローラーアクションを誰が、いつ、何をするかのタイプテーブルに記録するフィルターを実装しようとしています。

編集: とにかく監査テーブルが存在することが明らかな更新された質問を考慮して、監査テーブルへのリンクを選択する必要があります。一貫性のない監査データを持つという考えは、あまりにも恐ろしいものです! リレーショナル デザインによってアプリが完全に機能しなくなっていない限り、正規化を維持してください。

于 2011-06-29T15:59:49.460 に答える