Bonjour, je travaille actuellement sur une solution à un problème similaire, je le résous en divisant mes tables en deux, une table de contrôle et une table de données. La table de contrôle contiendra une clé primaire et une référence dans la table de données, la table de données contiendra une clé de révision à incrémentation automatique et la clé primaire de la table de contrôle comme clé étrangère.
en prenant votre table d'entrées comme exemple
Entries Table
+----+-------+------+--------+--------+
| id | title | text | index1 | index2 |
+----+-------+------+--------+--------+
devient
entries entries_data
+----+----------+ +----------+----+--------+------+--------+--------+
| id | revision | | revision | id | title | text | index1 | index2 |
+----+----------+ +----------+----+--------+------+--------+--------+
interroger
select * from entries join entries_data on entries.revision = entries_data.revision;
au lieu de mettre à jour la table des entrées_données, vous utilisez une instruction d'insertion, puis mettez à jour la révision de la table des entrées avec la nouvelle révision de la table des entrées.
L'avantage de ce système est que vous pouvez passer à différentes révisions simplement en modifiant la propriété de révision dans le tableau des entrées. L'inconvénient est que vous devez mettre à jour vos requêtes. J'intègre actuellement cela dans une couche ORM afin que les développeurs n'aient de toute façon pas à se soucier d'écrire du SQL. Une autre idée avec laquelle je joue est qu'il y ait une table de révision centralisée que toutes les tables de données utilisent. Cela vous permettrait de décrire l'état de la base de données avec un seul numéro de révision, similaire au fonctionnement des numéros de révision subversion.
