数週間前に、自分の CMS で data_versioning を作成しました。アイデアはとてもシンプルでした。data_versioning
いくつかのフィールドを持つ追加のデータベース テーブルを使用します。
- dv_id
- dv_table
- dv_primary_key
- dv_data
- dv_created_by
- dv_created_at
dv_id はテーブルの主キー、dv_created_by は user_id、dv_created_at は日時フィールドです。これらは重要度の低いフィールドです。3 つの重要なフィールドは次のとおりです。
- dv_table : このフィールドには、たとえば、データベース テーブルの名前が含まれます
students
。
- dv_primary_key : このフィールドには、テーブルの主キーが含まれ
students
ます。data_vesion がどの行にあるのかを特定します。
- dv_data : 以前に行にあったデータの配列のシリアル化された文字列が含まれています
私が使用した方法は次のとおりです。
- 行の編集ページは、最初にデータをチェックしてフェッチし、変数に格納します。次に例を示します。
$studentData = $db->fetch("SELECT * FROM students WHERE id = 1");
- POST リクエストが見つかると、新しいエントリがデータベースに対して有効であることを確認するためだけに、POST のフィールドがチェック (検証) されます。
- エントリが有効になるとすぐに、「魔法」が起こります
魔法は:
- 挿入する data_version を作成します。
$db->query("INSERT INTO data_version (dv_table, dv_primary_key, dv_data) VALUES ('students', 1, '".serialize($studentData)."')");
- 次に、現在の行を更新します。
$db->update("UPDATE students SET ... WHERE id = 1");
- $studentData 配列を新しいデータで更新します。
$studentData = $_POST;
パート 3 はオプションです。私の場合、誰かが変更を送信した後、テーブルを更新し、成功/エラー メッセージを表示すると、新しいデータを含む編集フォームが再び利用可能になります。この編集には$studentData
.. が入力されるため、この配列を更新する必要があります。そうしないと、前のエントリのデータが含まれます (ページの上部に $studentData が入力されるため)。
データの復元
データの復元は、dv_table フィールドと dv_primary_key フィールドに基づいてテーブル data_versions から利用可能なバージョンのリストを取得するのと同じくらい簡単です。次に、dv_data フィールドを unserialize() し、データを更新します。dv_data フィールドにはテーブル フィールドが含まれます
OO 統合は少し異なります。その場合、保存ハンドラーに追加の before() 関数を配置して、data_version テーブルに書き込むだけです。
これが最良の選択肢かどうかはわかりません。しかし、私の場合、 の代わりにデータベーステーブルを 1 つだけ必要とするソリューションを探していましstudents_versions
たnews_versions
。