A défaut de voir comment font les autres, en cherchant des idées et des "best practices" je suis tombé sur cet article que je note ici quand je me plongerais là dedans :
https://esj.com/articles/2011/03/01/fiv ... ables.aspx
L'idée suggérée (dans sa version simple) reprend le principe que j'évoquais avec une seule table : existence dans la même table d'autant de lignes qu'il y a eu de modification d'une fiche. Sauf que je n'avais pas pensé que l'id qui était unique allait être différent pour chaque version d'une fiche et qu'il faudrait donc ajouter un champ pour garder le lien vers la précédente version. Dans l'article, l'idée est que le clé primaire n'est plus le id_point mais le couple id_point,date_modification de sorte que l'on puisse garder le même id pour toutes les versions d'un point, seul le plus récent étant l'actif."Actif" n'ayant plus de raison d'être un champ puisque le plus récent étant l'actif. Une modif consiste alors à dupliquer l'actif et mettre à jour la date_modification, il devient alors automatiquement le nouvel actif.
Il y aurait donc a ajouter seulement 3 champs : un champ date_modif, auteur_modif et pourquoi pas un champs "raison_modif"
La clé primaire étant alors id/date_modif et le champs d'auto-incrément restant valable pour les ajouts de nouveaux points.
A creuser parce que ça n'est pas tout à fait fini: les commentaires sont rattachés à un id de de fiche, il faudrait voir ce qu'on fait lorsqu'un commentaire est modifié/supprimé et à quelle(s) version de fiche ancienne il se rattache.
Et p'tet que les messages forum on va pas trop y toucher !
Bref, structurellement je vois à peu près comment faire, le code existant passant tout par les fonctions (modèle ?
) spécial "points" ça devrait pas trop faire de code à corriger/tester. Mais alors coté interface, faut pouvoir voir les anciennes versions, afficher les différences, et pouvoir revenir à n'importe quelle ancienne version.
Y'a du taf
A défaut de voir comment font les autres, en cherchant des idées et des "best practices" je suis tombé sur cet article que je note ici quand je me plongerais là dedans :
https://esj.com/articles/2011/03/01/five-tips-managing-version-tables.aspx
L'idée suggérée (dans sa version simple) reprend le principe que j'évoquais avec une seule table : existence dans la même table d'autant de lignes qu'il y a eu de modification d'une fiche. Sauf que je n'avais pas pensé que l'id qui était unique allait être différent pour chaque version d'une fiche et qu'il faudrait donc ajouter un champ pour garder le lien vers la précédente version. Dans l'article, l'idée est que le clé primaire n'est plus le id_point mais le couple id_point,date_modification de sorte que l'on puisse garder le même id pour toutes les versions d'un point, seul le plus récent étant l'actif."Actif" n'ayant plus de raison d'être un champ puisque le plus récent étant l'actif. Une modif consiste alors à dupliquer l'actif et mettre à jour la date_modification, il devient alors automatiquement le nouvel actif.
Il y aurait donc a ajouter seulement 3 champs : un champ date_modif, auteur_modif et pourquoi pas un champs "raison_modif"
La clé primaire étant alors id/date_modif et le champs d'auto-incrément restant valable pour les ajouts de nouveaux points.
A creuser parce que ça n'est pas tout à fait fini: les commentaires sont rattachés à un id de de fiche, il faudrait voir ce qu'on fait lorsqu'un commentaire est modifié/supprimé et à quelle(s) version de fiche ancienne il se rattache.
Et p'tet que les messages forum on va pas trop y toucher !
Bref, structurellement je vois à peu près comment faire, le code existant passant tout par les fonctions (modèle ? ;-) ) spécial "points" ça devrait pas trop faire de code à corriger/tester. Mais alors coté interface, faut pouvoir voir les anciennes versions, afficher les différences, et pouvoir revenir à n'importe quelle ancienne version.
Y'a du taf