On dirait que vous essayez d'implémenter une Temporal Database . La prise en charge temporelle a été l'un des principaux ajouts à la norme ANSI/ISO SQL:2011. MySQL (comme la plupart des RDBMS) est en retard par rapport à la norme. Considérez la base de données temporelle comme l'équivalent SGBD de CVS/SVN/Git.
En revanche, la base de données traditionnelle que nous utilisons sans caractéristiques temporelles peut être appelée une base de données actuelle .
Dans une base de données actuelle , si vous essayez d'implémenter un support temporel, vous pouvez échouer de plusieurs manières avec différentes approches :
-
L'approche à table unique. Lorsque vous devez apporter des modifications, vous faites des
UPDATEssur vos enregistrements d'origine, et à moins que vous n'ayez une sorte de logique de déclenchement/d'audit maison, la trace de l'historique est absente. Même si vous disposez d'un journal d'audit/des modifications, vous devrez faire quelques recherches pour reconstituer l'historique des modifications. -
L'approche à deux tables. Au lieu d'apporter des modifications sur place, vous divisez vos données en deux tables, une avec les enregistrements de base/d'origine (par exemple, la réservation) et une autre table pour vos changements/modifications/deltas. Ensuite, au moins, vos données d'origine sont préservées, mais encore une fois, vous devez écrire une logique complexe pour afficher les données d'origine avec des modifications superposées. C'est encore pire si vous n'en voulez que quelques des modifications appliquées.
-
L'approche du tableau résultant précalculé . Vous gardez 3 tables ou plus :les enregistrements de la base, les modifications, et aussi une table qui tente de toujours avoir la résultante (maintient à jour la base + les modifications). Bonne chance pour écrire les déclencheurs et les procédures pour faire ce calcul chaque fois que vous faites des
INSERTs, et Heaven vous aide si uneUPDATEsouDELETEest nécessaire. La configuration est fragile et peut se désynchroniser, comme des blocages et des retours en arrière. Si vous ne le faites pas dans la base de données avec des déclencheurs/procédures, vous pouvez essayer d'implémenter le calcul résultant dans le code de l'application, mais ayez de la chance - et cela pourrait devenir moche avec des consommateurs multithreads. Et pourtant, vous n'avez pas facilement accès aux résultats avec seulement certains modifications appliquées.
Conclusion : Si vous n'êtes pas limité à MySQL, vous devriez vraiment envisager d'utiliser une base de données dotée d'un support temporel intégré. Sinon, vous allez réimplémenter la roue.
