Salut, c'est Nico de Code Garage.
Code Garage, qu'est-ce que c'est ? C'est un site qui regroupe des ressources gratuites
et des formations payantes pour que les devs puissent s'améliorer, faire de la veille
et continuer et passer de junior à senior.
Aujourd'hui, dans cet épisode, on va parler de ce qu'est une transaction en base de données.
Quand vous faites une requête à l'intérieur d'une base de données en SQL ou noSQL, peu
importe, cette requête va être exécutée, la base de données va être modifiée ou pas
et éventuellement, vous retournez des données.
Mais si jamais pour x, y raisons, votre base de données rencontre un problème, ça peut
être logiciel, système matériel ou même d'ordre extérieur, à au même moment que
vous faites votre requête ou vos requêtes, vous aurez à corriger l'incident avant de
pouvoir continuer à utiliser vos données avec le dernier état connu.
Si, par exemple, avant votre dernière requête, l'incident a empêché la requête de finir
de s'exécuter, il va y avoir une partie des requêtes qui ont été exécutées, l'autre
non, ça va poser un problème.
Théoriquement, sauf évidemment perte de données dû à l'incident, votre programme
pourra être relancé et fonctionné normalement.
Mais si on imagine le même scénario sur une application critique comme un système
de virement bancaire, le scénario est un peu différent.
On va simplifier au maximum le système de virement et on va dire que chaque transfert
d'argent, ça nécessite au minimum deux opérations.
D'abord le retrait de l'argent envoyé sur le compte débiteur et ensuite l'ajout
de l'argent reçu sur le compte créditeur.
Avec ces deux opérations successives, représentées de manière logicielle par deux requêtes distinctes
à la base de données, ça introduit une possibilité de perte de l'intégrité des
données contenues dans la base.
Si on n'a jamais un problème entre les deux.
Imaginons que notre serveur de base de données subisse un incident, peu importe lequel pendant
l'opération, il y a deux possibilités.
C'est soit un des comptes à reçu l'argent mais personne n'a été débité, donc le
système a virtuellement créé de l'argent, soit un des comptes a été débité mais
l'argent n'a jamais été reçu donc il a disparu.
Évidemment, c'est impensable pour un système de gestion financière et pas que de laisser
la porte ouverte à un tel risque.
C'est pour cette raison que la majorité des systèmes de gestion de base de données
implémentent une fonctionnalité pour pallier à ce problème et c'est ce qu'on appelle
des transactions.
Pour comprendre le mécanisme des transactions, il faut qu'on revienne un petit peu plus
en arrière sur un autre concept plus général qui est l'atomicité.
L'origine du mot « atom » ça veut dire « inséquable » donc qu'on ne peut pas
couper.
En informatique, on parle d'opérations atomiques quand plusieurs opérations sont réalisées
de manière séquentielle mais indissociables, l'une après l'autre, mais on veut absolument
que les deux opérations se passent.
Dans notre exemple par nom précédent, c'est exactement ce genre d'opération atomique
dont on aurait besoin que le débit et le crédit ne puissent pas exister l'un sans
l'autre.
Et bien pour effectuer un ensemble d'opérations atomiques dans une base de données, on va
créer une transaction qui va faire en sorte que l'intégrité des données soit conservée
même en cas d'incident.
Pour ça, on va découvrir deux concepts qui sont le commit et le rollback.
Évidemment pour simplifier la compréhension, on va décomposer la création d'une transaction
et des requêtes qui la contiennent en plusieurs étapes.
D'abord, on va créer et configurer une nouvelle transaction.
Ensuite, on va créer une copie totale ou partielle de l'état actuel de la base de
données, c'est ce qu'on appelle un snapshot qui va être réservé à cette transaction.
On va exécuter une ou plusieurs requêtes dans une opération atomique sur les données
du snapshot.
Et donc selon le résultat de l'exécution des deux opérations, il y a deux solutions
qui s'offrent à nous.
Si tout s'est bien passé, alors on demandera de commit le résultat des opérations.
Donc le snapshot qu'on a copié sera alors fusionné avec la base d'origine.
Si un problème est survenu entre temps, alors on demandera un rollback.
Le snapshot sera supprimé et aucune des opérations n'aura été exécutée sur la
base de données.
Évidemment, là je vous ai donné un petit peu une vision très rapide de l'implémentation
des transactions, mais ça peut en réalité différer selon l'implémentation de chacune
des bases de données.
Mais le principe général reste le même et j'espère vous avez alors fait comprendre
l'importance cruciale dans la gestion des données de la mise en place de transactions
et d'opérations atomiques.
Alors si jamais pour aller plus loin, ça vous intéresse et que vous vous demandez
comment plusieurs transactions concurrentes peuvent s'orchestrer et évidemment ne pas
se marcher dessus, je vous recommande un article qui est en anglais, mais qui explique très
bien les différentes stratégies mises en place par les différents systèmes de gestion
de base de données.
Je vous mettrai le lien dans les notes du podcast.
J'espère que cet épisode vous aura été utile pour en comprendre un petit peu plus
sur la théorie des bases de données.
Moi je vais simplement vous encourager à mettre cinq étoiles à ce podcast pour tout
simplement le faire monter dans les référencements et le faire découvrir à plus de personnes
et je vous dis à très vite sur le site de code garage, code-garage.fr.
C'était Nico, à la semaine prochaine.