13

Undo-Redo を許可するように DB テーブルを設計する方法を見つけようとしています。

次の構造を持つタスクテーブルがあるとします。

id <int>
title <varchar>
memo <string>
date_added <datetime>
date_due <datetime>

ここで、数日にわたって複数のログインが行われ、複数の編集が行われたと仮定します。しかし、ユーザーはいずれかのバージョンに戻りたいと考えています。

  1. 変更を追跡する別のテーブルを用意しますか?それとも、タスクテーブル内に変更を保持しようとしますか(より適切な用語がないため、「ゴースト」行)。
  2. すべての列を追跡しますか、それとも毎回変更された列だけを追跡しますか?

問題があれば、MySQL を使用しています。また、問題があれば、履歴 (ala Photoshop) を表示して、ユーザーが任意のバージョンに切り替えられるようにしたいと考えています。

おまけの質問:memo変更時にセル全体を保存しますか、それともデルタのみを保存しようとしますか? 私が尋ねる理由は、memoセルが大きくなる可能性があり、リビジョンごとに 1 つの単語または文字のみが変更される可能性があるためです。確かに、デルタを保存するには解析が必要ですが、元に戻す操作がそれほど頻繁に行われないと予想される場合は、処理時間よりもスペースを節約する方がよいのではないでしょうか?

ご協力ありがとうございました。

4

3 に答える 3

8

タスクテーブルの履歴テーブルを作成します。タスクと同じ構造+previousIdという名前の新しいフィールド。これにより、前の変更IDが保持されるため、さまざまな変更（元に戻す/やり直し）を前後に行うことができます。

なぜ新しい履歴テーブルなのですか？単純な理由で：タスクテーブルを設計されていないものでオーバーロードしないでください。

スペースに関しては、履歴では、メモの代わりにバイナリ形式を使用して、保存するテキストのコンテンツを圧縮します。変更を検出しようとしないでください。バグのあるコードに遭遇し、フラストレーションと時間の浪費につながります...

最適化：さらに良いことに、履歴テーブルには3つの列のみを保持できます。1。taskId（タスクへの外部キー）2。データ-バイナリフィールド。履歴テーブルに保存する前に、変更されたフィールドのみを保持するXML文字列を作成します。3. previousId（変更のキューを維持し、前後のナビゲーションを可能にするのに役立ちます）

データフィールドについては、次のようなXML文字列を作成します。

<task>
  <title>Title was changed</title>
  <date_added>2011-03-26 01:29:22<date_added>
</task>

これは基本的に、今回はtitleフィールドとdate_addedフィールドのみを変更したことを示しています。

XML文字列が作成されたら、必要に応じてそれを圧縮して、履歴テーブルのデータフィールドに保存します。

XMLは柔軟性も可能にします。タスクテーブルのフィールドを追加/削除する場合、履歴テーブルも更新する必要はありません。したがって、このようにして、タスクテーブルと履歴テーブルの構造が分離され、毎回2つのテーブルを更新する必要がなくなります。

PS：履歴テーブルをすばやくナビゲートするために、いくつかのインデックスを追加することを忘れないでください。インデックスを作成するフィールド：このテーブルに対する高速クエリが必要になるため、taskIdとpreviousId。

お役に立てれば。

于 2011-03-26T00:56:45.577 に答える
3

SQLを使用して同様のタイプのことを行う場合、リビジョン履歴には常に2番目のテーブルを使用します。これにより、バージョンによってプライマリテーブルが大きくなりすぎるのを防ぐことができます。理論的根拠は、現在のレコードの取得はほぼ100％の時間で発生し、履歴の表示とロールバック（元に戻す）は非常にまれであるということです。

UNDOまたは履歴が1つしかない場合は、テーブル内での追跡で問題ない可能性があります。

デルタを保存するか、セル全体を保存するかは、予想される成長/使用量によって異なります。デルタを管理するロジックを作成することに慣れている場合は、スペースを節約できます。物事が実際に新しいバージョンを作成しない場合、それから始めないことがよくあります（YAGNIを適用）

于 2011-03-26T00:36:22.110 に答える
3

リビジョンをデルタ形式で圧縮したい場合がありますが、すぐに取得できるように現在のリビジョン全体を保持する必要があります。

ただし、基になる非デルタがない限り、古いものから新しいものへのデルタには多くの処理が必要です。新しいものから古いものへのデルタでは、何かが変更されるたびに再処理が必要になります。したがって、デルタは通常、多くの利点をもたらすわけではなく、より複雑になります。

私が最後にチェックしたのは数年前で、ウィキペディアの背後にあるソフトウェアであるMediaWikiは全文を保存し、古いリビジョンを gzip で圧縮してスペースを節約する手段と、archive削除されたリビジョン/ページ専用のテーブルを提供していました。

彼らのウェブサイトには、役に立つと思われるデータベース レイアウトの ER ダイアグラムがあります。

于 2011-03-26T00:53:09.490 に答える