Cześć, obecnie pracuję nad rozwiązaniem podobnego problemu, rozwiązuję go, dzieląc moje tabele na dwie, tabelę kontrolną i tabelę danych. Tabela sterująca będzie zawierała klucz główny i odniesienie do tabeli danych, tabela danych będzie zawierała klucz automatycznej inkrementacji wersji oraz klucz podstawowy tabeli sterującej jako klucz obcy.
biorąc jako przykład tabelę wpisów
Entries Table
+----+-------+------+--------+--------+
| id | title | text | index1 | index2 |
+----+-------+------+--------+--------+
staje się
entries entries_data
+----+----------+ +----------+----+--------+------+--------+--------+
| id | revision | | revision | id | title | text | index1 | index2 |
+----+----------+ +----------+----+--------+------+--------+--------+
do zapytania
select * from entries join entries_data on entries.revision = entries_data.revision;
zamiast aktualizować tabelę wpisów_danych, używasz instrukcji INSERT, a następnie aktualizujesz wersję tabeli wpisów o nową wersję tabeli wpisów.
Zaletą tego systemu jest to, że możesz przejść do różnych wersji, po prostu zmieniając właściwość wersji w tabeli wpisów. Wadą jest konieczność aktualizacji zapytań. Obecnie integruję to z warstwą ORM, więc programiści i tak nie muszą się martwić o pisanie SQL. Innym pomysłem, z którym się bawię, jest stworzenie scentralizowanej tabeli poprawek, z której korzystają wszystkie tabele danych. Umożliwiłoby to opisanie stanu bazy danych za pomocą jednego numeru wersji, podobnie jak działają numery wersji subversion.
