MySQLデータベースでリレーショナルデータをバージョン管理するためのパターン?


12

ユーザーがレコードを編集し、それらのレコードの過去のバージョンを表示できるプロジェクトのアプローチを見つけようとしています。リストを使用した、簡単なスキーマの例を次に示します。

TABLE list (
  id int auto_increment primary key,
  user_id int, 
  title varchar(255)
);

TABLE list_tasks (
  id int auto_increment primary key,
  list_id int,
  title varchar(255),
  order int,
  is_complete tinyint
);

したがって、ユーザーがリストにアクセスして、リストにいくつかの編集を加え(タスクの追加または削除、タスクの並べ替え、完了のマーク付け、名前の変更など)、保存します。この時点で、リストとタスクの「バージョン2」を生成し、以前のバージョンを表示できるようにしますが、リストにアクセスするときは常に最新バージョンを取得します。

MySQLデータベースでこのようにバージョン管理データを処理するための一般的なアプローチ/設計パターンはありますか?


これらはこのためのライブラリであることに注意してください。たとえば、Hibernateを使用する場合、Hibernate Enversがあります。したがって、DAOを処理するフレームワークがある場合は、このようなものがあるかどうか検索してみてください。
ウォルフラット

回答:


9

dbでそれをしたいのはかなり一般的です。アイテムのリストの改訂を追跡するという点で、ひねりを加えています。

これを行う1つの方法は、次のような構造を変更することです。

Alter table lists add revision_id integer;
Alter table list_tasks add revision_id integer;

Create Table revisions
{
   id int autoincrement... (revision id)
   list_id int...
   revdate datetime...
}

ユーザーがリストを保存したら、revisions上の表で新しいリビジョンを作成し、その値をリストアイテムにlist_tasks、次にリビジョンIDに割り当てて、listsそのIDを「現在の」リビジョンとしてマークします。ユーザーがアイテムを編集するときは、既存のアイテムを編集しないでください。新しいリビジョンIDを持つ新しいアイテムを挿入し、listそのリビジョンでテーブルを更新して、現在のアイテムとしてマークします。

次に、現在のアイテムをリストするには、listsテーブルで指定された現在のリビジョンIDからアイテムをリストします。以前のバージョンを参照するには、リビジョンテーブルからリストの以前の改訂のリストを取得し、そのIDに基づいて個々のアイテムをリストします。


5

このソリューションでは、個別の監査テーブルを使用します。長所と短所があります。メインテーブルから古いレコードを削除することもできます。パフォーマンスの改善はごくわずかです。

監査対象の各テーブルに次のフィールドを追加します。

AddUserID      int <whatever your system uses>
AddDateTime    datetime
UpdateUserID   int <whatever your system uses>
UpdateDateTime datetime
CurrentVersion int
IsDeleted      bit

データが変更されるたびに、これらのフィールドを更新する必要があります。CurrentVersionは1ずつ増加します(レコードをロックする方法として使用できますが、それは別の質問です)。IsDeletedは、将来参照できるように「ソフト削除」を提供します。

個別の監査テーブル 各テーブルには、対応する_Archiveまたは_Historyバージョンのテーブルが必要です。これらは、おそらく同じ方法でインデックスを作成する必要はありません。明らかに、単一の主キーフィールドは適用されません。IDフィールドとUpdateDateTimeから複合キーを作成できるはずです。

トリガー(これはコードの内部または外部で行われた変更に対処します。状況に応じて機能するかどうかを決定できます。)または他のコーディング(レコードが追加、更新、削除されると、レコードのコピーがアーカイブに配置されます) / historyテーブル。すべてのバージョンと他の監査フィールドが維持されます。これにより、ユーザーが何をいつ実行したかがわかります。テーブルをそれ自体と比較して、レコードがいつ変更されたか、または傾向を確認できます。

この作品はここ数年よく見ました。私が考慮していないかもしれない欠点について聞きたいです。


私はこれとGrandMasterBを支持しています。どちらも優れており、どちらを使用するかは特定のニーズの詳細に依存します。
ジャンキー

-2

この詳細な記事を読むことをお勧めします。

https://blog.jondh.me.uk/2011/11/relational-database-versioning-strategies/comment-page-1/#comment-373850

別のアプローチは、テーブルにversion_id列と、現在の行を指定する 'current'フラグを設定することです。更新が必要になるたびに、新しい行を挿入し、既存のバージョンの「現在の」フラグを0 / falseに設定し、新しく追加した行を1に設定できます。

このようにして、現在のフラグが設定されているビューのみを表示するビューを作成できます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.