Quand j'ai vu l'implémentation de l '«historique des enregistrements» - versionnage, du côté du programme travaillant avec la base de données SQL. Avant de modifier l'enregistrement, l'ancienne version a été obtenue de la base de données, écrite en XML et la chaîne XML résultante a été écrite dans une table de version distincte.
Initialement, dans son programme, il prévoyait de faire du versionnage un peu plus tard, il n'y avait aucun besoin urgent. Je me souviens qu'il y avait un désir d'utiliser le type de données jsonb quelque part, dès que j'ai pensé à une implémentation simple et concise du versioning côté SQL, je n'ai pas pu le faire. Une seule table de version avec 5 colonnes et une fonction de déclenchement dans 3 lignes de code.
Pour décrire l'implémentation d'une table de version ne suffit pas, vous devez donc décrire quelques autres tables par exemple.
Dans presque toutes les bases de données, à de rares exceptions près, il existe une table d'utilisateurs - utilisateurs. Il est utile de stocker l'historique des modifications - versions de l'utilisateur, par exemple, pour la possibilité de revenir à l'ancienne version, par les forces de l'utilisateur.
Exemple de table utilisateur:
Les deux derniers champs de l'image sont nécessaires pour la table des versions, ils peuvent également être appelés "auteur de la version" et "date de version", mais, si vous le souhaitez, vous pouvez vous en passer.
Tableau des versions:
Fonction de déclenchement pour l'enregistrement des versions:
Les deux premiers champs sont remplis à partir de l'enregistrement enregistré OLD.changestamp et OLD.userid.
Dans la table des versions, non seulement les entrées de la table des utilisateurs peuvent être stockées, le troisième champ est le hachage MD5 du nom de la table versionnée, converti en uuid.
Les exemples décrits précédemment décrivaient une structure très simple, mais en règle générale, diverses données de référence peuvent avoir des tables supplémentaires avec une relation un-à-plusieurs.
Par exemple, le tableau «Groupes d'utilisateurs».
Et le deuxième tableau est «Utilisateurs du groupe», la composition du groupe est les utilisateurs du groupe.
Afin de ne pas compliquer le mécanisme de versioning simple, vous pouvez effectuer une légère duplication des données dans la table des groupes, ajoutez un champ jsonb qui répète la structure de la table "Group Users".
Pour simplifier le travail avec les données dupliquées, vous pouvez créer une fonction de déclenchement supplémentaire, avec INSERT ou UPDATE, en remplissant le tableau "Group Users" du champ jsonb.
La duplication décrite ci-dessus n'est nécessaire que lorsqu'elle est nécessaire pour obtenir des données de la table souvent et aussi rapidement que possible. Par exemple, si une requête est souvent envoyée à la table "Utilisateurs du groupe" pour déterminer si un utilisateur est membre du groupe Administrateurs. Dans d'autres cas, les données peuvent être obtenues par requête directement à partir du champ jsonb et ne pas utiliser de table en double.
L'exemple de code complet est ici