私が取り組んでいるプロジェクトでは、レコードにデジタルで「署名」する必要があり、その後、変更を加えると行の新しい「バージョン」が作成されます。「署名済み」レコードは、規制上の理由から変更できず、新しいバージョンを頻繁に変更するべきではありません。これまでは、メイン テーブルと同じスキーマで別のログ テーブルを作成し、誰がいつ変更したかを追跡するための追加の列を作成していました。
ただし、すべてのデータ (さまざまなバージョンを含む) が同じテーブルに配置される SharePoint でいくつかの作業を行った後、私は別のアプローチを考えました。同じテーブルで、バージョン番号を増やします。次に、バージョン番号を PK に追加します。
長所:
- 実装は簡単です。「署名済み」行の更新ではなく挿入を実行する「更新の代わりに」トリガーを作成するだけです。トリガーで更新する IsCurrentVersion 列を簡単に追加できます。
- 古いバージョンのクエリは簡単です。必要な ID を持つすべてのレコードを取得して、ユーザーがリストから選択できるようにするだけです。
- トリガーは、署名されている場合に行を更新できないことを保証するため (規制および監査の目的で) 便利です。
- テーブルに対するスキーマの変更は、ミラーの "ログ" テーブルに複製する必要はありません。
短所:
- テーブルは少し大きくなる可能性がありますが、ほとんどの場合、レコードは「署名」後に変更されません。クライアントは、現在の使用レベルで最大約 100,000 行/年と見積もっています。SQL Server は数億行を処理できるため、これはそれほど悪いことではないように思えます。
- インデックス作成とパフォーマンスが問題になる可能性があります。SharePoint は tp_CalculatedVersion int を PK に追加します。計算された数値は常に最新バージョンの 0 です。同じことを行い、バージョン番号に基づいて計算できます。それはパフォーマンスに役立ちますか?
最新バージョンを確実に取得するためにデータのクエリを実行する追加の手順がありますが、これは SP で処理できます。
このシナリオには他にどのような短所がありますか。私は何かが欠けていますか??