Lors de la conception de grandes bases de données relationnelles, nous prenons souvent la décision de nous écarter d'une forme normale, c'est-à-dire la dénormalisation.
Les raisons peuvent être différentes, telles qu'une tentative d'accélérer l'accès aux données spécifiées, les contraintes de la plate-forme/du cadre/des outils de développement utilisés et le manque de compétences d'un développeur/concepteur de base de données.
Au sens strict, une référence aux contraintes du cadre, etc. est en fait une tentative de justifier le manque de compétences.
Les données dénormalisées sont une vulnérabilité, à travers laquelle il est facile d'amener notre base de données à un état non cohérent (non intégral).
Que pouvons-nous faire avec ça ?
Exemple
Dans une base de données, il y a un tableau avec certaines opérations financières :la réception et la disposition des fonds sur différents comptes.
Nous avons toujours besoin de connaître le solde du compte.
Dans les données normalisées, le solde du fonds est toujours une valeur calculée. Nous allons calculer le total des recettes sans débiter.
Cependant, il est trop coûteux de calculer le solde à chaque fois qu'il y a beaucoup d'opérations. Par conséquent, il a été décidé de stocker le solde réel dans un tableau séparé. Comment mettre à jour les données de ce tableau ?
La solution est "comme d'habitude"
Presque dans tous les systèmes d'information avec lesquels j'ai eu à travailler, cette tâche était réalisée par une application externe, qui implémentait la logique métier. Vous avez de la chance si l'application est simple et qu'il n'y a qu'un seul point de changement de données, à partir du formulaire dans l'interface utilisateur. Cependant, que se passe-t-il s'il y a des importations, des API, des applications tierces, etc. effectuées par différentes personnes et équipes ? Que se passe-t-il s'il y a plusieurs tableaux avec des totaux au lieu d'un ? Que faire s'il y a plus d'une table avec des opérations ?
Il devient de plus en plus difficile de surveiller si un développeur a mis à jour un ensemble de tables lors de la mise à jour des opérations. Les données perdent leur intégrité. Le solde du compte ne correspond pas aux opérations. Bien sûr, les tests doivent révéler de telles situations. Cependant, notre monde n'est pas idéal.
Déclencheurs
Comme alternative, les déclencheurs sont utilisés pour contrôler l'intégrité des données dénormalisées.
J'ai entendu dire que les déclencheurs ralentissaient considérablement une base de données, donc les utiliser n'a aucun sens.
Le deuxième argument était que toute la logique réside dans une application distincte et qu'il est déraisonnable de conserver la logique métier à différents endroits.
Découvrons.
Décalages
Un déclencheur se déclenche à l'intérieur de la transaction qui modifie les données de la table. La transaction ne peut pas être terminée tant que le déclencheur n'a pas exécuté les étapes requises. Par conséquent, la conclusion est que les déclencheurs doivent être "légers".
L'exemple de la requête "lourde" dans le déclencheur est le suivant :
update totals set total = select sum(operations.amount) from operations where operations.account = current_account where totals.account = current_account
Une requête fait référence à la table avec des opérations et résume le montant total des opérations pour le compte .
Lorsque la base de données augmente, une telle requête consommera de plus en plus de temps et de ressources. Cependant, nous pouvons obtenir le même résultat en utilisant la requête légère du type suivant :
update totals set total = totals.total + current_amount where totals.account = current_account
Lors de l'ajout d'une nouvelle ligne, ce déclencheur augmentera simplement le total du compte sans le calculer. Le total ne dépend pas de la quantité de données dans les tables. Cela n'a aucun sens de recalculer le total, car nous pouvons être sûrs que le déclencheur se déclenche à chaque fois lors de l'ajout d'une nouvelle opération.
La suppression ou la modification de lignes est traitée de la même manière. Les déclencheurs de ce type ne ralentiront pas les opérations, mais assureront le couplage et l'intégrité des données.
Chaque fois que j'ai rencontré des "décalages" lors de l'ajout de données à une table avec un déclencheur, c'était un exemple d'une telle requête "lourde". Dans la plupart des cas, il était possible de le réécrire dans une requête "facile".
Logique métier
Il faut distinguer les fonctions qui assurent l'intégrité des données de la logique métier. Dans chaque cas, je pose une question si les données étaient normalisées, aurions-nous besoin d'une telle fonction ? S'il est positif, la fonction est une logique métier. S'il est négatif, la fonction est d'assurer l'intégrité des données. Vous pouvez encapsuler ces fonctions dans des déclencheurs.
Cependant, il existe une opinion selon laquelle il est facile d'implémenter toute la logique métier via un SGBD, tel que PostgreSQL ou Oracle.
J'espère que cet article vous aidera à réduire le nombre de bugs dans votre système d'information.
Bien sûr, je suis loin de penser que tout ce qui est écrit ici est la vérité ultime. Dans la vraie vie, bien sûr, tout est beaucoup plus compliqué. Par conséquent, vous devez prendre une décision dans chaque cas spécifique. Utilisez votre esprit d'ingénieur !
P.S.
- Dans l'article, j'ai attiré l'attention sur le seul aspect de l'utilisation des déclencheurs en tant qu'outil puissant.
- L'approche décrite dans l'article permet d'éviter les index dans les Opérations table, qui, à son tour, peut accélérer le processus d'ajout de données à cette table. À des volumes élevés, cette approche compense facilement le temps passé sur le déclencheur.
- Il est important de comprendre quels outils nous devons utiliser. Dans ce cas, vous éviterez de nombreux problèmes.
