データベースの履歴

Question

どのテーブルにどのような変更が行われたかを記録する方法を体系化する最も効果的な方法は何ですか？例えば、データベーススキーマには約10-12のテーブルがあり、テーブルには約7-8のテーブルを結合してレコードが表示されます。さまざまなユーザーが行った変更を同じレコードまたは別のレコードに同期させるにはどうすればよいですか。

アプローチA：行アクティベータ/デアクティクタフラグを持つことによって。レコードが更新されたときに非アクティブ化フラグを設定します。レコードが更新されると、行が無効化され、アクティベータフラグが設定された新しいレコードが挿入されます。

アプローチB：タイムスタンプにデータwrtを格納するすべてのテーブルについて、個別のデータベース履歴テーブルを更新します。

仮定：レコードは頻繁に更新されます。予想されるレコードの合計数は1000行を超えないようにする必要があります。

提案したいと思う方法はありますか？

Answer 1

を、私はあなたが特定のレコードの履歴を確認する必要がありますどのくらいの頻度」、答えは質問にあると思います

監査を行うときに何をしたのかを調査するために時折この情報を必要とする場合は、監査テーブルアプローチを使用して、各データの変更に対応します。または、変更トラッキングを使用している場合は（監査のための十分な情報がないと率直に）チェンジトラッキングを使用して、最後のデータインポート以降にレコードが変更されたかどうかを確認することもできます。変更追跡データは、別のテーブルに物理的にコピーしない限り、永続的ではありません。

履歴全体を頻繁に表示する必要がある場合は、トリガーを介してアクティブなフラグが設定された1つのテーブルにすべての履歴を保存してください。最新のデータのみを表示する場合に使用する開発者向けのアクティブなレコードのみを持つビューを作成します。以前に履歴を保存していない既存のデータベースにこの作業を行っている場合は、テーブルの名前を変更して、ビューに同じ名前のテーブルを指定してください。

レポート用の履歴データが必要な場合は、別の履歴テーブルを使用することを検討しますが、アプリケーションの残りの部分は考慮しません。私たちは、営業担当者が話している目標が実際には高価値目標であるかどうかを知る必要があるので、これがあります。これは、営業担当者のパフォーマンスを測定する方法の一部であるためです。明らかに私たちは歴史を必要としていますが、実際には月に1回ほどしかありません。そのため、同じ表に保管するために毎日のパフォーマンス低下が最良の解決策ではないかもしれません。これは、時間のかかるレポート作成を日々のものから遠ざけるのに役立ち、一般的にパフォーマンスを助けるかもしれません。

Answer 2

変更の追跡： http://msdn.microsoft.com/en-us/library/cc305322.aspx

それとも

チェンジ・データ・キャプチャ：http://msdn.microsoft.com/en-us/library/cc645937.aspx