Imaginez que vous transférez 200 000 € d’un compte bancaire à un autre. Vous retirez le montant du compte source, puis vous le déposez sur le compte de destination. Jusqu’ici, tout est normal et, dans un monde parfait, l’opération sera réussie. Malheureusement, dans le monde réel, les choses peuvent mal tourner. Quelque chose se produit et l’argent est perdu. C’est très mauvais.
Eh bien, les transactions sont là pour faire en sorte que cela n’arrive pas avec vos applications ! Dans cet article de blog, nous allons explorer en détail l’utilisation et l’importance des transactions, ainsi que plusieurs scénarios montrant comment elles peuvent sauver votre entreprise.
Que sont les transactions ?
Selon la documentation:
Les transactions sont une série de modifications de données connexes apportées à une base de données dans le cadre d’un processus. Une transaction n’est pas enregistrée de façon permanente dans une base de données tant qu’elle n’est pas validée. Si une transaction n’est pas terminée, soit parce qu’elle est annulée, soit en raison d’un événement extérieur, les modifications ne sont pas enregistrées.
Il est important de noter :
Lorsque vous utilisez des transactions imbriquées, le résultat de chaque sous-transaction dépend de la validation ou de l’annulation de la transaction de niveau supérieur. Si la transaction de niveau supérieur est validée, les résultats des sous-transactions sont confirmés (validation ou annulation). En revanche, si la transaction de niveau supérieur est annulée, toutes les sous-transactions sont annulées, quels que soient leurs résultats respectifs.
N’hésitez pas à consulter la documentation pour obtenir des informations plus détaillées sur les transactions.
Utilisation des transactions
Il est difficile d’imaginer des applications commerciales qui n’utilisent pas de transactions, et pourtant j’en ai vu de temps en temps ! En discutant de cette absence de transactions avec les développeurs d’applications, j’ai entendu des phrases comme « oh, ça a marché jusqu’à présent », ou même « nous avons toujours eu de la chance ». À mon avis, la chance ne devrait pas être un concept de conception pour les applications de gestion.
La comptabilité est un exemple classique d’utilisation des transactions. Les états financiers fournissent un enregistrement de deux catégories : les actifs et les passifs. Les deux doivent être calculés et enregistrés (complètement, jamais partiellement), ou ne pas être touchés du tout.
Un autre exemple est un système d’expédition, où la création d’une commande diminue le stock dans l’entrepôt. Plutôt que de compter sur la chance, nous devons nous assurer que les enregistrements de la commande et de l’inventaire sont créés ou modifiés ensemble. Quoi qu’il arrive, soit les deux opérations sont réalisées, soit elles sont annulées.
Vous pouvez considérer une transaction comme une sorte de grosse parenthèse :
- Vous l’ouvrez (START TRANSACTION commande),
- effectuer des opérations dans la base de données (créer/modifier/supprimer des enregistrements – d’une ou plusieurs tables),
- puis vous la fermez soit en la validant (VALIDATE TRANSACTION commande) ou en annulant (CANCEL TRANSACTION commande) TOUTES les opérations.
Outre les opérations de base de données de bas niveau, l’interface utilisateur est un autre bon exemple d’utilisation des transactions. Imaginez un formulaire de saisie de facture, utilisant une zone de liste (ou un sous-formulaire) avec des articles de produits (stockés dans une autre table) … ou des clients et des contacts … ou des contacts et des numéros de téléphone. La liste est longue. ….
Votre utilisateur souhaite modifier une facture. Il peut modifier un ou plusieurs éléments, puis décider finalement de cliquer sur le bouton d’annulation et supposer que toutes les modifications apportées aux éléments de la facture sont annulées (non enregistrées). Vous pouvez gérer cela avec des tableaux complexes ou simplement en utilisant une transaction.
Avec un peu de chance, vous utilisez déjà des transactions.
Utilisation de transactions imbriquées
Premier scénario : une application Contact
Disons que vous avez une structure simple avec deux tables : clients et contacts. Vous disposez d’un formulaire de saisie pour les clients comprenant une liste d’enregistrements de contacts. Un double-clic sur un enregistrement ouvre un formulaire de saisie de contact avec plus de détails sur le contact.
Voici ce qui peut se passer :
- Un utilisateur final ouvre un enregistrement client et modifie le nom de la rue.
- Il ouvre ensuite le contact « A », modifie la date de naissance, puis ferme le formulaire de contact en cliquant sur le bouton OK.
- Il ouvre ensuite le contact « B », modifie quelque chose, puis décide d’annuler ses changements.
- De retour au formulaire du client, l’utilisateur final clique sur un bouton OK pour terminer ses activités.
L’utilisateur s’attend à ce que sa modification du contact « A » soit sauvegardée, mais pas celle du contact « B ». Les modifications apportées à l’enregistrement du client lui-même doivent, bien entendu, être également enregistrées.
Avec les transactions imbriquées, cela est facile à gérer. Il suffit d’utiliser une transaction dans le formulaire du client et une autre dans le formulaire du contact. Pas de problème !
Deuxième scénario : traitement automatique par lots
Le traitement automatique par lots (calculs, importations, etc.) est un scénario totalement différent, mais qui repose sur le même concept :
- Au milieu d’un traitement par lots complexe, vous devez interrompre le processus pour une raison quelconque(par exemple, si vous rencontrez des données erronées ou si l’utilisateur demande d’annuler/de quitter).
Avec une transaction à un seul niveau, vous ne pouvez qu’annuler toutes les opérations – ou vous arrêter au milieu, ce qui entraîne une situation peu claire. Vous pensez peut-être « Je ne m’arrêterais pas au milieu, je terminerais l’opération avant de m’arrêter ». C’est très bien, mais comment gérer les pannes de courant, les crashs, les défaillances matérielles et autres erreurs inattendues ?
Puisque vous ne pouvez pas… et que compter sur la chance n’est pas fiable… le système doit être conçu pour garantir des données fiables.
N’oubliez pas…
Les transactions vous permettent de contrôler ce genre de situations. Utilisez des transactions individuelles pour chaque opération (importation de données, exécution de calculs, etc.) imbriquées dans une transaction de niveau supérieur (pour permettre l’annulation ou la validation de toutes les opérations).
Si une transaction n’aboutit pas pour une raison quelconque (crash, panne de courant, etc.), n’ayez crainte ! Chaque opération déjà effectuée est annulée car rien n’a encore été validé par la transaction de niveau supérieur.