3

データベース内のデータのリビジョン管理を作成しています。リビジョン、ロールバック、およびロールバック ロールバックを保存する機能があります。私が使用している、修正が必要なデータベース テーブルは次のとおりです。

オブジェクト
object_chunks
object_attributes

オブジェクトは主要なオブジェクトであり、チャンクはオブジェクトのセクションをグループ化したものであり、属性はチャンク内のデータの属性です。属性はオブジェクト ID をチャンク ID と一緒に保存します。オブジェクトのすべての属性を選択するのは簡単で、チャンク テーブルに対して別の JOIN を実行する必要はありません。

実際に変更されるのは属性だけですが、属性が変更されると、影響を受けるチャンクが更新され、チャンクが更新されるたびにオブジェクトも更新されます。今、私はこの問題を解決する 2 つの異なる方法を考えました。

  1. _rev のサフィックスを持つ 3 つの新しいテーブルを作成します。これらのテーブルは、オブジェクトの古いバージョンを格納するだけです。実際のオブジェクトには、rev 番号も格納されます。つまり、3 つの異なる属性を変更したとしましょう。これらの属性は 3 つのチャンクにまたがっており、チャンクに 3 つの新しい行、属性に 3 つ、リビジョン用のオブジェクトに 1 つの新しい行が含まれています。これは最初の変更であるため、rev ID は 1 になり、実際のテーブルでは rev は 2 になります。
  2. 上記を単純に実行しますが、別のテーブルを作成する代わりに、単純に同じテーブルに格納します。

注意すべきことの 1 つは、常に改訂があり、チャンクの量は 1 から 100+ まで変化する可能性があることです。平均は約1〜15ですが。属性は 0 から 100+ まで変化します。平均はおそらく 30 前後です。すべての属性が変更されます。これらのオブジェクトは、ユーザーがすべての属性を入力する必要がある「フェーズ」を通過します。それらがいっぱいになると、オブジェクトはアーカイブされ、二度と変更されることはありません。すべてのオブジェクトには、対応するファイルがあります。そのため、オブジェクトはファイルの現在のハッシュ (sha256) も格納します。このハッシュは、重複排除の目的で使用されます。

4

2 に答える 2

3

オブジェクト テーブルの主キーにリビジョン ID を追加することは間違いなく正しい方法です。複数のアクティブなリビジョンを持つことができ、テーブル間でデータを移動する必要はありません。複数のテーブルを使用すると、整合性の制約を維持しながらデータを移動するロールバック アルゴリズムを作成するのが難しくなります。システムが活発に開発されている場合は特に困難です。

リビジョンが人間の時間で作成された場合、単純なタイムスタンプがリビジョン ID として機能することがあります。それ以外の場合は、リビジョン番号として整数を使用してください。CVS スタイルのドット付きリビジョン番号を実装しましたが、実装しないことを望みました。人々が後でその機能を求めた場合は、派生履歴を別の表で追跡できます。

于 2010-01-10T20:08:11.417 に答える
0

どうですか

objects object_chunks revision object_attributes

リビジョンが増加する数である場合、オブジェクトごとに最大 (リビジョン) グループ化されたオブジェクト、将来的には object_chunks を選択するだけで済みます。

于 2010-01-10T19:33:26.170 に答える