1

SQLServer2005。

このアプリケーションでは、親テーブルといくつかの子テーブルを持つエンティティがあります。このエンティティに加えられた改訂を追跡したいと思います。行ったり来たりした後、2つのアプローチから選択するように絞り込みました。

  1. エンティティの履歴テーブルを1つ用意します。sprocがテーブルを更新する前に、親テーブルとすべての子テーブルからエンティティの現在の状態全体を取得します。それをXML化し、XMLデータ型として履歴テーブルに貼り付けます。クエリする列と、リビジョン番号/作成日を含めます。

  2. テーブルごとに、同じ列を持つ一致する履歴テーブルを作成します。改訂番号/作成日もあります。sprocが単一のテーブルを更新する前に、その1つのテーブルのレコードの既存の状態を取得し、それを履歴テーブルにコピーします。つまり、SVNに少し似ています。リビジョンYのエンティティを取得する場合は、各テーブルの履歴レコードを取得する必要があります。最大リビジョン数はY以下です。エンティティの1つのテーブルに50のリビジョンレコードがある場合がありますが、子テーブルなど。エンティティ全体のリビジョンカウンターをどこかに保持したいと思うでしょう。

どちらのアプローチにも頭痛の種があるようですが、それでも私はソリューション＃1よりもソリューション＃2の方が好きです。これはすでに巨大なデータベースであり、すでにパフォーマンスの問題に悩まされています。すべてのリビジョンでXMLブロブを使用してそれを膨らませること（そしてたくさんあるでしょう）は、恐ろしい方法のように思えます。すべての履歴テーブルを作成することは、これを行うためのより良い方法がない限り、私が喜んで食べるコストです。

助言がありますか？

ありがとう、Tedderz

4

1 に答える 1

3

番号2はほぼ確実に進むべき道であり、タイムスタンプを使用する代わりに「イベント」テーブルを使用して変更を相互に関連付けることもできますが、履歴テーブルでこのようなことを行います。これが「リビジョンカウンター」の意味だと思います。私の「イベント」テーブルには、一意のID、タイムスタンプ（もちろん）、変更を担当するアプリケーションユーザー、および変更を発生させたユーザーが行ったアプリケーションレベルのアクションを表す「アクション」指定子が含まれています。

なぜ＃2？テーブルをより簡単に分割して、古いエントリをアーカイブまたはロールオフできるためです。インデックス付けが簡単だからです。クエリが非常に簡単だからです。XMLよりもオーバーヘッドが少なく、はるかに小さいためです。

また、これらすべてを実行するために、ストアドプロシージャをコーディングする代わりに、トリガーを使用することを検討してください。トリガーはほとんどの場合回避する必要がありますが、このような場合、トリガーはこの種のことを実行するためのかなり軽量で堅牢な方法です。

于 2012-09-18T01:26:13.287 に答える