Hallo, ich arbeite derzeit an einer Lösung für ein ähnliches Problem. Ich löse es, indem ich meine Tabellen in zwei Teile aufteile, eine Steuertabelle und eine Datentabelle. Die Steuertabelle enthält einen Primärschlüssel und einen Verweis auf die Datentabelle, die Datentabelle enthält den Autoinkrement-Revisionsschlüssel und den Primärschlüssel der Steuertabelle als Fremdschlüssel.
am Beispiel Ihrer Einträge-Tabelle
Entries Table
+----+-------+------+--------+--------+
| id | title | text | index1 | index2 |
+----+-------+------+--------+--------+
wird
entries entries_data
+----+----------+ +----------+----+--------+------+--------+--------+
| id | revision | | revision | id | title | text | index1 | index2 |
+----+----------+ +----------+----+--------+------+--------+--------+
abzufragen
select * from entries join entries_data on entries.revision = entries_data.revision;
Anstatt die Tabelle entries_data zu aktualisieren, verwenden Sie eine Einfügeanweisung und aktualisieren dann die Revision der Entries-Tabelle mit der neuen Revision der Entries-Tabelle.
Der Vorteil dieses Systems besteht darin, dass Sie zu anderen Revisionen wechseln können, indem Sie einfach die Revisionseigenschaft in der Eintragstabelle ändern. Der Nachteil ist, dass Sie Ihre Abfragen aktualisieren müssen. Ich integriere dies derzeit in eine ORM-Schicht, damit sich die Entwickler sowieso keine Gedanken über das Schreiben von SQL machen müssen. Eine andere Idee, mit der ich spiele, ist, dass es eine zentralisierte Revisionstabelle gibt, die alle Datentabellen verwenden. Dies würde es Ihnen ermöglichen, den Zustand der Datenbank mit einer einzigen Revisionsnummer zu beschreiben, ähnlich wie Subversion-Revisionsnummern funktionieren.
