私は最近、データベース設計に関する非常に興味深い問題に出くわしました。問題を単純化するためにテーブル名を変更したので、次のように説明します。果物や野菜がおいしいかどうかに関係なく、果物と野菜の 2 つのテーブルがあります。
ここで、誰かが私のアプリケーションの UI を介して IsTasty 設定を変更し続けており、管理者が誰かが最後に変更したのはいつか、誰が変更したかを確認する機能を要求しているとします。ここで注意が必要なのは、テーブルの他のデータを無視しているにもかかわらず、他のデータがあり、テーブルのデータがいつ変更されたかを追跡したくなく、この 1 つの列だけを追跡することです。
この問題を解決する最善の方法は何ですか?
私は、acts_as_versioned プラグインが Rails でそれを行う方法が気に入っています。バージョン番号フィールドが追加されたソリューション 2 に最も近いものです。基本的に、fruits テーブルと fruit_versions テーブルがあります。果物の行が更新されるたびに、バージョン番号が増分された同じデータをfruits_versions テーブルに挿入します。
テーブルにさらにフィールドを追加したり、追加の値を追跡したりする場合は、ソリューション 3 のアプローチよりも拡張性があると思います。ソリューション 4 は一種の非リレーショナル ソリューションです。おそらく、そのような監査ログを保持できます。
バージョンを維持するのとは対照的に、別のアプローチは、subversion やバージョン管理システムのように、変更を追跡することです。これにより、何かが a から b に変化したかどうかを知りたい場合や、何に変化したかだけを知りたい場合に、作業が簡単になります。つまり、本当の答えは、データがどのように使用されるかによって「依存する」ということです。
SQL Server 2008 を使用している場合は、CDC (Change Data Capture) を調べましたか?
SQL Server では、AutoAuditを使用してトリガーを生成します。監査テーブルには履歴が含まれており、ビューを使用して変更を表示できます (AutoAudit は、削除された行のビューを自動的に作成します)。
SQL Server 2005 以降を使用すると、次のような if ステートメントでトリガーを作成できます。
IF UPDATE(IsTasty)
BEGIN
Insert INTO Log (ID, NewValue) VALUES (@ID, @NewValue)
END
これを行う 1 つの方法は、これらのテーブルにトリガーを追加することです。トリガーで、関心のある列が変更されたかどうかを確認します。変更されている場合は、変更を追跡する別のテーブルに行を挿入します。変更追跡テーブルには、変更された列の名前、以前の値、新しい値、および変更日などのデータを格納する必要がある場合があります。
Triggerには、変更された列を確認する方法があります。