こんにちは、現在同様の問題の解決に取り組んでいます。テーブルを制御テーブルとデータテーブルの2つに分割することで解決しています。制御テーブルには主キーとデータテーブルへの参照が含まれ、データテーブルには自動インクリメントリビジョンキーと外部キーとしての制御テーブルの主キーが含まれます。
例としてエントリテーブルを取り上げます
Entries Table
+----+-------+------+--------+--------+
| id | title | text | index1 | index2 |
+----+-------+------+--------+--------+
になります
entries entries_data
+----+----------+ +----------+----+--------+------+--------+--------+
| id | revision | | revision | id | title | text | index1 | index2 |
+----+----------+ +----------+----+--------+------+--------+--------+
クエリする
select * from entries join entries_data on entries.revision = entries_data.revision;
エントリテーブルを更新する代わりに、挿入ステートメントを使用してから、エントリテーブルのリビジョンをエントリテーブルの新しいリビジョンで更新します。
このシステムの利点は、エントリテーブル内のリビジョンプロパティを変更するだけで、別のリビジョンに移動できることです。欠点は、クエリを更新する必要があることです。私は現在これをORMレイヤーに統合しているので、開発者はとにかくSQLを書くことを心配する必要はありません。私がいじっているもう1つのアイデアは、すべてのデータテーブルが使用する一元化されたリビジョンテーブルがあることです。これにより、Subversionのリビジョン番号が機能するのと同じように、単一のリビジョン番号でデータベースの状態を説明できます。