4

たとえば、製品のテーブルがあるとします。作成者、最終編集者、最終更新日などのログ情報を保存する必要がありますか...または、ログ情報が実際のアプリケーションに関連しない場合、監査テーブルなどにログ情報を分離する必要がありますか?

ありがとうございました。

4

8 に答える 8

5

監査情報を保持することに真剣に取り組んでいる場合は、別のテーブルに入れる必要があります。最後に更新されたものは上書きされるだけで、代わりにはなりません。キーにタイムスタンプを追加すると、履歴を同じテーブルに保持できますが、クエリのコストが高くなり、アプリケーション ロジックが複雑になるという犠牲を払うことになるため、これはお勧めしません。

于 2010-05-14T13:16:24.050 に答える
4

通常、LastChangeUser と LastChangeDate 列の情報を各テーブルに保持し、CreateUser と CreateDate も含める場合があります。これは通常、ほとんどのテーブルに適しています。

ただし、それ以上を保存する必要がある場合、本当に重要なテーブル (通常はお金に関連するもの) については、別のテーブルに移動してください。そのテーブル (OriginalTableName_History) には、通常、自動インクリメントである HistoryID、HistoryDate、および HistoryType (I=insert、U=update、D=delete)、および元のテーブルのすべての列があります。私は通常、すべての変更 (挿入/更新/削除) を履歴テーブルに入れる単一のトリガーをメイン テーブルに配置します。

于 2010-05-14T13:27:21.677 に答える
3

別のテーブルに持っている方が良いだろうと簡単に言います。

于 2010-05-14T13:13:12.047 に答える
3

運用データベース (製品、顧客などに関する現在の情報) をログ ストレージから常に分離する必要があります。場合によっては、「履歴」データベースを作成し、そこにすべてのレガシー データを保存して、運用データベースを過負荷にしないこともお勧めします。巨大なデータベースで選択を行うのは常に遅いため、可能な限りサイズを縮小し、インデックスを作成してパフォーマンスを向上させる必要があります。ログ情報は、他のデータベースに保存する必要があります。「最終更新者」のようなフィールドは、ログ情報とは見なしません。必要なテーブルにそれらを含めることができます。また、データ管理も遅くなるため、運用データベース (運用データを直接参照せずにログ情報を保存する) にあまり多くの外部キーを持たないようにすることをお勧めします。

それが役に立てば幸い。

于 2010-05-14T13:55:26.437 に答える
1

特に監査証跡を維持したい場合は、別に保管します。エンティティでログを記録するということは、エンティティごとに 1 つのログ エントリしか持てないことを意味します。また、個別の懸念事項が混在しています。エンティティへの変更とエンティティ自体は別個の概念であり、個別のテーブルに配置するのが最適です。

結合されたテーブルでは、エンティティを削除すると、そのエンティティのすべての監査情報が削除されますが、これは望ましくない場合があります。

于 2010-05-14T13:14:31.580 に答える
1

アプリケーションと保存する情報の量によって異なります。Ruby on Rails などの一部のフレームワークは、created_by などのフィールドを自動的に更新できます。そのため、その柔軟性があり、フィールドが 2 つしか必要ない場合は、同じテーブルに保持する方が簡単かもしれません。

ただし、誰がいつレコードを変更したかなど、詳細な情報をログに記録する場合は、別のテーブルを使用することをお勧めします。そうすれば、監査目的で、レコードに加えられたすべての変更の履歴を保持することもできます.

于 2010-05-14T13:15:38.170 に答える
1

各製品についてログに記録している一連のメタデータは増加する可能性がありますか? その場合は、アイテムを追加できるように別のテーブルに配置します。

成長しない具体的なセットであれば、おそらく問題にはなりません。別のテーブルを使用することで、概念的なエレガンスを少し得ることができますが、効率と複雑さはわずかに失われます。

于 2010-05-14T13:16:39.480 に答える
1

アプリケーションが製品の現在の属性を知るだけでよい場合は、監査情報を別のテーブルに配置するのが適切です。これにより、クエリが簡素化され、パフォーマンスが向上します。

一方、特定の時点でエンティティを再構築できるようにする必要がある場合 (たとえば、「2004 年にこの製品を販売したブランドは?」という質問にアプリケーションが定期的に答える必要がある場合)。 should never change records : エンティティへの変更はエンティティのデータの一部であり、同じテーブルにある必要があります。(オブジェクト指向の文脈でこれについての良い議論については、Martin Fowler の記事「時間とともに変化するもののパターン」を参照してください。)

于 2010-05-14T13:27:05.243 に答える