複数の関連データのリビジョン管理

Question

私は何らかの理由でそのデータに戻す必要がある場合に備えて、リビジョン/履歴情報を複数行のリビジョンに保存する方法を理解しようとしています。

これは、レイアウトの一般的なものです：

item 
--------------- 
id 
title 
etc... 

region 
--------------- 
id 
title 
etc... 

release_type 
----------------- 
id 
title 
etc... 

items_released_dates_data 
--------------------- 
item_id 
region_id 
release_type_id (these three form the primary key) 
date 

ですから、+のregion_id + release_type項目ごとにリリース日を持つことができ、我々は基本的にのみ、この質問の目的のために日付（「日付」を追跡します

新しいデータが追加されると変更がサブミットされますitems_released_dates_dataのすべてitem_id = your_idが最初に削除されてから挿入されますステートメントは新しい値を追加します（おそらくこれを行う最良の方法ではありません）

説明に更新された内容の要約を作成し、すぐにクライアントにデコードすることができ、JSONやXMLか何かのようないくつかの形式のデータを含む

items_release_dates_data_history 
------------------------------------- 
item_id 
timestamp 
description 
raw_data 

：

私の考えはのような表を作成することでしたユーザーに変更のレビューと、指定されたバージョンへの変更の選択肢を提供します。 items_released_dates_dataへのすべてのエントリにitems_released_dates_data_historyへのエントリが必要です（質問のように聞こえません：：）

ここで役に立つと思われるmysqlトリガについて読んだことがありますが、彼らについてのことを知っているので、私は理解しているところで働いています。

私の質問は、この記事のバージョンへの正しい道をたどっています。この方法を改善する方法について誰かが私に与えることができるアドバイス/ベストプラクティスはありますか？

Answer 1

私は2番目のAlex Millerのコメントです。あなたが書いたものはすべてこれまでのところ意味があります。

ご予約にもかかわらず、トリガーを調べることを強くおすすめします。彼らは把握が非常に簡単で、そのようなシナリオでは非常に強力なツールになります。トリガを使用すると、レコードが更新（または削除）されるたびに、行のコピーを別のテーブルに格納できます。トリガ内で、入ってくるデータを既存のデータと比較し、変更されたものだけを書き込むことができます。

MyISAMやInnoDBの代わりに、これらの種類のテーブル用のアーカイブストレージエンジンも考えてください。このような種類のジョブ用に作られています。

また、探している検索語句は「監査証跡」です。

Answer 2

私はあなたが間違いなく正しい道にいると言いたいと思います。リージョンIDを履歴に保存して、アイテム全体ではなくリージョンに基づいてリリース履歴を確認することができます。

delete + insertは、あまりにも多くのトラフィックで終了しない限り、両方のロックアクションです。行を挿入または削除して索引を更新するときには、多くの時間が使用されます。 MyISAMテーブルを使用している場合、それらのアクションが完了するまで、テーブル上のすべての読み取りを停止します。アップデートも同様ですが、はるかに短い時間です。 InnoDBは行をロックするだけなので、それは本当に懸念事項ではありません。