Здравейте, в момента работя върху решение на подобен проблем, решавам го, като разделям таблиците си на две, контролна таблица и таблица с данни. Контролната таблица ще съдържа първичен ключ и препратка към таблицата с данни, таблицата с данни ще съдържа автоматично увеличаващ се ключ за ревизия и първичния ключ на контролната таблица като външен ключ.
като вземем вашата таблица с записи като пример
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;
вместо да актуализирате таблицата entries_data, вие използвате израз за вмъкване и след това актуализирате ревизията на таблицата с записи с новата ревизия на таблицата с записи.
Предимството на тази система е, че можете да преминете към различни ревизии просто като промените свойството на ревизията в таблицата с записи. Недостатъкът е, че трябва да актуализирате вашите заявки. В момента интегрирам това в ORM слой, така че разработчиците да не се притесняват да пишат SQL така или иначе. Друга идея, с която си играя, е да има централизирана таблица за ревизии, която да използват всички таблици с данни. Това би ви позволило да опишете състоянието на базата данни с един номер на ревизия, подобно на начина, по който работят номерата на ревизиите на subversion.
