3

私が取り組んでいるプロジェクトでは、レコードにデジタルで「署名」する必要があり、その後、変更を加えると行の新しい「バージョン」が作成されます。「署名済み」レコードは、規制上の理由から変更できず、新しいバージョンを頻繁に変更するべきではありません。これまでは、メイン テーブルと同じスキーマで別のログ テーブルを作成し、誰がいつ変更したかを追跡するための追加の列を作成していました。

ただし、すべてのデータ (さまざまなバージョンを含む) が同じテーブルに配置される SharePoint でいくつかの作業を行った後、私は別のアプローチを考えました。同じテーブルで、バージョン番号を増やします。次に、バージョン番号を PK に追加します。

長所:

  • 実装は簡単です。「署名済み」行の更新ではなく挿入を実行する「更新の代わりに」トリガーを作成するだけです。トリガーで更新する IsCurrentVersion 列を簡単に追加できます。
  • 古いバージョンのクエリは簡単です。必要な ID を持つすべてのレコードを取得して、ユーザーがリストから選択できるようにするだけです。
  • トリガーは、署名されている場合に行を更新できないことを保証するため (規制および監査の目的で) 便利です。
  • テーブルに対するスキーマの変更は、ミラーの "ログ" テーブルに複製する必要はありません。

短所：

  • テーブルは少し大きくなる可能性がありますが、ほとんどの場合、レコードは「署名」後に変更されません。クライアントは、現在の使用レベルで最大約 100,000 行/年と見積もっています。SQL Server は数億行を処理できるため、これはそれほど悪いことではないように思えます。
  • インデックス作成とパフォーマンスが問題になる可能性があります。SharePoint は tp_CalculatedVersion int を PK に追加します。計算された数値は常に最新バージョンの 0 です。同じことを行い、バージョン番号に基づいて計算できます。それはパフォーマンスに役立ちますか？

  • 最新バージョンを確実に取得するためにデータのクエリを実行する追加の手順がありますが、これは SP で処理できます。

  • このシナリオには他にどのような短所がありますか。私は何かが欠けていますか??

4

3 に答える 3

3

このパターンがエンタープライズ システムで使用されているのを見たことがありますが、IMO は成功しませんでした。

  • ここでは、ライブ データと監査データの保存という 2 つの異なる懸念事項を混在させています。このテーブルへのクエリは、リーフ データまたは監査データ (レポートなど) を探しているかどうかを常に念頭に置く必要があります。新しいチーム メンバーは、これが直感的でないと感じる場合があります。この複雑さをビューなどでカプセル化する必要があるでしょう。
  • あなたが言ったように、パフォーマンスは常に懸念されます。新しいレコードを挿入すると、以前のレコードも更新して非アクティブとしてマークする必要があります。すべてのバージョンを同じページに保持するには、クラスター化インデックスを変更することも検討する必要があります。
  • このテーブルへの外部キーが問題になります。正確なバージョン レコードを参照していますか? 次に、新しいライブ リーフ レコードを指すように外部キーを修正しますか?

これを行うことで考えられる利点の 1 つは、監査テーブルの DDL が常にライブ テーブルと同期されることです。多くの場合、2 つのテーブル戦略がライブ テーブルに変更され、監査とトリガーの DDL がそれに応じて更新されません。

全体として、監査テーブルを別にしておくことをお勧めします。

于 2012-08-09T18:30:28.370 に答える
2

署名されたデータを変更しないことが要件である場合は、それを別のテーブルに移動する必要があります。実際、テーブルで許可されている唯一の操作がレコードの挿入と読み取りである別のデータベース/スキーマに移動することをお勧めします。本当に更新を防止したい場合は、パーミッションとトリガーの両方を使用できます。

規制要件をいじりたくはありません。主キーとバージョンの組み合わせとトリガーを使用する複雑なスキーマは、より簡単な方法がある可能性があることを示しています。

過去のレコードは、現在のレコードのパフォーマンスに影響を与える可能性があります。すべてのレコードが 100 回変更された状況になった場合、それらを同じテーブルに保持すると、クエリが遅くなるだけです。もちろん、データを分割するという形で、より複雑にすることもできます。結局、解決策はより簡単です。変更できないデータを、変更できない別のテーブルに保持します。多くの履歴が蓄積されたからといって、ハードウェアをアップグレードする必要はありません。

また、履歴記録に発効日と終了日を含めることをお勧めします。これにより、特定の日付の時点でのすべてのデータを再構築できます。これは、ユーザーが将来役立つ可能性があるものです。

于 2012-08-09T18:10:09.450 に答える
1

それは正しい。監査証跡は、内部レポート/監査のアプリケーションにとどまることができますが、infosecのベストプラクティスでは、監査ログをシステムから取得して、ログ管理/SIEMソリューションに生成することが義務付けられています。

于 2012-09-25T23:35:56.580 に答える