sql - オブジェクトのフィールド変更を追跡するための最適なアーキテクチャは何ですか？

Question

SQLデータベースの上に構築されたWebアプリケーションがあります。いくつかの異なるタイプのオブジェクトにコメントを追加できます。これらのオブジェクトの一部には、ほとんどの問題追跡システム（ステータス、割り当て、優先度など）でフィールドの変更を追跡する方法と同様に、フィールドレベルの追跡が必要です。誰が変更したのか、以前の値は何だったのか、新しい値は何なのかを示したいと思います。

純粋な設計レベルでは、オブジェクトタイプ、オブジェクトの主キー、変更を行ったユーザーの主キー、フィールド名、および古い値と新しい値。私たちの場合、ユーザーが変更を行うときにコメントを入力した場合、これらにはオプションでコメントIDもあります。

ただし、このデータがどれだけ急速に増大する可能性があるので、これは最高のアーキテクチャですか？このタイプの機能をすでに大規模なアプリケーションに追加するために一般的に採用されている方法は何ですか？

[編集]私はこの質問に賞金をかけ始めています。主な理由は、スケールの処理に関して特に最適なアーキテクチャを見つけたいからです。Tom H.の答えは有益ですが、推奨される解決策はかなりサイズ効率が悪いようで（多くの列が変更されていなくても、オブジェクトの新しい状態ごとに新しい行が表示されます）、ユーザーが作成したフィールドへの変更も追跡できます。特に、一般的な問題追跡システム（JIRAなど）がこれをどのように実装したかを説明できる回答を受け入れる可能性があります。

Answer 1

これにはいくつかのオプションがあります。基本的に基本テーブルをミラーリングするだけでなく、変更日時、変更タイプ、およびユーザーを含む監査テーブルを作成できます。これらは、トリガーを介して更新できます。ただし、このソリューションは、通常、アプリケーション固有の要件を解決するよりも、舞台裏の監査（IMO）に適しています。

2番目のオプションはあなたが説明した通りです。どの属性が変更されたかを示すタイプコードを使用して、個々の変更を保持する汎用テーブルを作成できます。このソリューションは、列でのチェック制約の使用を防ぎ、外部キー制約も防ぐことができるため、個人的には好きではありません。

3番目のオプション（与えられた情報で私の最初の選択になります）は、アプリケーションを通じて更新され、各テーブルのPKと追跡する列を含む個別の履歴変更テーブルを持つことです。 。アプリケーションが必要に応じてテーブルを更新する責任があるという点で、最初のオプションとは少し異なります。監査のようなバックエンドの技術的要件ではなく、解決しようとしているビジネス要件が実際にあるため、私はあなたの場合の最初のオプションよりもこれを好みます。アプリケーションにロジックを配置することで、もう少し柔軟性があります。メンテナンスの更新などのために追跡したくない変更があるかもしれません。

3番目のオプションでは、ベーステーブルに「現在の」データを含めるか、履歴テーブルにのみ履歴を保持する各列を含めることができます。次に、オブジェクトの現在の状態を取得するために、最新の行を確認する必要があります。データベース内のデータが重複したり、同じデータについて複数のテーブルを調べたりする必要がなくなるため、これをお勧めします。

だから、あなたは持っているかもしれません：

Problem_Ticket（ticket_id、ticket_name）Problem_Ticket_History（ticket_id、change_datetime、description、comment、username）

または、次を使用することもできます。

Problem_Ticket（ticket_id、ticket_name）Problem_Ticket_Comments（ticket_id、change_datetime、comment、username）Problem_Ticket_Statuses（ticket_id、change_datetime、status_id、username）

Answer 2

「問題追跡」固有のアプローチについてはよくわかりませんが、これを行うための究極の方法が1つあるとは言えません。それを達成するためのいくつかのオプションがあり、ここに示されているように、それぞれに長所と短所があります。

私は個人的に、変更に関するいくつかのメタデータ列と、古いオブジェクトのシリアル化されたバージョンまたはあなたが気にかけているもののxmlを格納する列を持つ1つのテーブルを作成します。そうすれば、オブジェクトの履歴を表示したい場合は、すべての古いバージョンを取得し、それらを再水和して完了します。それらすべてを支配する1つのテーブル。

見過ごされがちな解決策の1つは、ChangeDataCaptureを使用することです。これにより、本当に心配している場合は、スペースの節約/パフォーマンスが向上する可能性があります。

幸運を。

Answer 3

正確な要件によって異なりますが、これは適切ではない場合がありますが、トリガーを使用したデータベースでの一般的な監査（フロントエンドやSPインターフェイスレイヤーも関係ありません）では、AutoAuditを使用します。これは非常にうまく機能します。 。

Answer 4

これがあなたの目的を達成するために私がお勧めする解決策です。

以下に示すように、監査モデルを設計します。

  ---------------- 1 * ------------                       
 | AuditEventType | ---------- | AuditEvent |                      
  ---------------- ------------                       
                                | 1 | 1                       
                                | |                         
               ----------------- -------------            
              | 0,1 | +         
    -----------------------------------   
   | AuditEventComment | | AuditDataTable |  
    -----------------------------------   
                                                     | 1         
                                                     |           
                                                     |           
                                                     | +         
          ----------------- + 1 --------------     
         | AuditDataColumn | ------------------ | AuditDataRow |   
          ----------------- --------------     

。

AuditEventType

システムで発生する可能性のあるすべてのイベントタイプのリストと、その一般的な説明が含まれています。

。

AuditEvent

このアクションをトリガーした特定の情報も含まれています。

。

AuditEventComment

監査イベントに関するオプションのカスタムユーザーコメントが含まれます。コメントは非常に大きくなる可能性があるため、CLOBに保存することをお勧めします。

。

AuditDataTable

それぞれのAuditEventの影響を受けた1つ以上のテーブルのリストが含まれています

。

AuditDataRow

それぞれのAuditEventの影響を受けたそれぞれのAuditDataTableの1つ以上の識別行のリストが含まれています

。

AuditDataColumn

以前の値と現在の値で値が変更された、それぞれのAuditDataRowの0個以上の列のリストが含まれます。

。

AuditBuilder

AuditBuilder（ビルダーパターン）を実装します。イベントの開始時にインスタンス化し、リクエストコンテキストで使用できるようにするか、他のDTOと一緒に渡します。コード内のどこかでデータに変更を加えるたびに、AuditBuilderで適切な呼び出しを呼び出して、変更について通知します。最後に、AuditBuilderでbuild（）を呼び出して上記の構造を形成し、それをデータベースに永続化します。

イベントのすべてのアクティビティが、監査データの永続性とともに単一のDBトランザクション内にあることを確認してください。

Answer 5

監査されたデータの実際の使用シナリオはわかりませんが...変更を追跡する必要がありますか？いくつかの変更を「ロールバック」する必要がありますか？監査ログレポート/ルックアップをどのくらいの頻度（かつ柔軟）にしますか？

個人的に私はそのようなことを調査します：

AuditTableを作成します。これには、ID、バージョン番号、ユーザーID、およびCLOBフィールドがあります。

• オブジェクト＃768795が作成されたら、次の値を使用してAuditTableに行を追加します。Id=＃768795バージョン：0ユーザー:(新しいオブジェクトを作成したユーザーのID）clob：オブジェクト全体のxml表現。（スペースに問題があり、このテーブルへのアクセスが頻繁でない場合は、blobを使用して、xml表現をその場で「zip」することができます）。

何かを変更するたびに、新しいバージョンを作成し、オブジェクト全体をXMLとして「シリアル化」して保存します。監査ログを作成する必要がある場合は、必要なものがすべて揃っており、簡単な「テキスト比較」ツールまたはライブラリを使用して確認できます。時間の経過とともに変化したもの（ウィキペディアのように）。

フィールドのサブセットのみを追跡する場合は、残りが不変であるか重要ではないか、速度/スペースが必要な場合は、気になるサブセットをシリアル化するだけです。

Answer 6

この質問は非常に古いことは知っていますが、SQLに組み込まれているもう1つの可能性は、トラックの変更です。

このリンクで詳細を確認できます：SQL Server 2008の変更データキャプチャ（CDC）の概要 http://www.simple-talk.com/sql/learn-sql-server/introduction-to-change-data-capture -（cdc）-in-sql-server-2008 /

Answer 7

このシナリオでは、オブザーバーが理想的なパターンだと思います。