4

データベース全体に間違ったエントリが含まれることがありますが、データを直接変更するのではなく、変更のリビジョンを保持できるようにしたいと考えています。

これらの変更はめったに発生しません。

理想的には次のようなもの： -

 (original table fields) | revision_version | origin | user | timestamp

たとえば、次のスキーマを持つpostsというテーブルがあるとします: -

title | description | timestamp | author

このようにして、 posts_revisionsという追加のテーブルが作成されます。

title | description | timestamp | author | revision_version | origin | user | timestamp
  • originは、ボット、ユーザーが生成したもの、またはあなたが持っているものなど、変更のソースです。

ご想像のとおり、これは既存のデータベースに対するかなり大きな変更であり、私の現在の懸念は、クエリごとに _revisions テーブルをチェックするパフォーマンスへの影響です。これは、この種のベストプラクティスですか?

4

2 に答える 2

2

この種の問題のために、現在のテーブルと履歴テーブルを保持しています。

履歴テーブルには、次の追加の列があります。

  • 履歴ID
  • 発効日
  • 終了日
  • バージョンナンバー
  • によって作成された
  • 作成日

有効日と終了日は、値が有効な期間です。バージョンは、レコードが変更されるたびにインクリメントされます。id、CreatedAt、および CreatedBy は、データベース内のほぼすべてのテーブルに配置する列です。

通常、私は、テーブルを比較し、MERGE を使用してデータを結合する夜間のジョブで、履歴テーブルを最新の状態に保ちます。別の方法は、すべての変更をストアド プロシージャにラップし、そこで両方のテーブルを更新することです。もう 1 つの方法は、変更が発生したことを検出するトリガーを使用することです。しかし、私は最初の 2 つの選択肢を好み、トリガーを敬遠します。

これらのテーブルでは、ディスク容量はそれほど重要ではないことを認めなければなりません。そのため、結果に 1 回、履歴に 1 回、データを 2 回保存しても問題はありません。履歴のみを履歴テーブルに保存し、現在のレコードを「現在の」テーブルに保存するのはちょっとした調整です。

このアプローチの欠点の 1 つは、ベース テーブルの構造を変更することです。列を追加する場合は、ベース テーブルだけでなく履歴テーブルにも追加する必要があります。

于 2012-08-02T13:52:28.943 に答える
1

テーブルが要約目的で使用される場合 (特に、ビジネス ユーザーが SQL アクセス権を持っている場合)、データを削除して別のテーブルに配置するのが最善だと思います。フラグとリビジョンは場合によっては問題ありませんが、その線に沿って何かをしなければならない場合、select sum(select someVar where revision_version=max(revision_version and someID=ID))それは本当に単純ではありません。

迅速で厄介なデータ収集に使用されているテーブルがある場合は、データを置き換え、必要に応じて古いデータをリビジョン テーブルに配置します。一部のアプリケーションのみがアクセスし、パフォーマンスの問題がない場合は、メイン テーブルに保持します。

于 2012-08-02T12:57:46.443 に答える