Hallo, ik werk momenteel aan een oplossing voor een soortgelijk probleem, ik los het op door mijn tabellen in tweeën te splitsen, een controletabel en een gegevenstabel. De controletabel bevat een primaire sleutel en een verwijzing naar de gegevenstabel, de gegevenstabel bevat de auto-incrementrevisiesleutel en de primaire sleutel van de controletabel als externe sleutel.
uw invoertabel als voorbeeld nemen
Entries Table
+----+-------+------+--------+--------+
| id | title | text | index1 | index2 |
+----+-------+------+--------+--------+
wordt
entries entries_data
+----+----------+ +----------+----+--------+------+--------+--------+
| id | revision | | revision | id | title | text | index1 | index2 |
+----+----------+ +----------+----+--------+------+--------+--------+
opvragen
select * from entries join entries_data on entries.revision = entries_data.revision;
in plaats van de tabel entries_data bij te werken, gebruikt u een insert-instructie en werkt u vervolgens de revisie van de invoertabel bij met de nieuwe revisie van de invoertabel.
Het voordeel van dit systeem is dat u naar verschillende revisies kunt gaan door simpelweg de revisie-eigenschap in de invoertabel te wijzigen. Het nadeel is dat u uw vragen moet bijwerken. Ik integreer dit momenteel in een ORM-laag, zodat de ontwikkelaars zich toch geen zorgen hoeven te maken over het schrijven van SQL. Een ander idee waar ik mee speel, is dat er een gecentraliseerde revisietabel komt die door alle datatabellen wordt gebruikt. Dit zou je in staat stellen om de staat van de database te beschrijven met een enkel revisienummer, vergelijkbaar met hoe subversion revisienummers werken.