TRANSACTION VISUALIZER

La distinction entre l’état temporaire en mémoire et l’état persisté en base est le point le plus difficile à assimiler dans les transactions SQL. Le visualiseur de transaction rend cet état explicite en affichant systématiquement les deux états côte à côte, avec un code couleur cohérent : jaune pour les modifications en attente, bleu pour les UPDATE, vert pour les INSERT acceptés, rouge pour les annulations, et vert foncé pour les lignes définitivement committées. Cette représentation spatiale remplace avantageusement les descriptions textuelles qui peinent à distinguer ce qui existe en mémoire de ce qui est réellement écrit sur disque.

Qu’est ce qu’une transaction et pourquoi elle est indispensable

Une transaction SQL est un bloc d’opérations traité comme une unité indivisible : soit toutes les opérations réussissent et sont validées ensemble, soit elles sont toutes annulées. Cette propriété s’appelle l’atomicité et constitue le premier des quatre principes ACID qui garantissent la fiabilité d’une base de données relationnelle. Sans transaction, un virement bancaire interrompu en plein milieu laisserait la base dans un état incohérent : le débit effectué, le crédit absent.

Le jeu de données de l’outil illustre précisément ce cas : une table comptes avec quatre titulaires (Alice, Bob, Claire, David) et leurs soldes respectifs. Toutes les opérations simulées — débit, crédit, insertion — portent sur ces mêmes données, ce qui permet de comparer visuellement l’état initial, l’état temporaire en mémoire, et l’état final après COMMIT ou ROLLBACK.

-- Jeu de données utilisé par l'outil
CREATE TABLE comptes (
  id        INT,
  titulaire VARCHAR(50),
  solde     DECIMAL(10, 2)
);

INSERT INTO comptes VALUES
  (1, 'Alice',  3000),
  (2, 'Bob',    1500),
  (3, 'Claire', 2200),
  (4, 'David',   800);

Les 3 scénarios proposés par l’outil

L’outil propose trois onglets navigables correspondant chacun à un comportement distinct des transactions. L’onglet COMMIT (vert) simule une transaction complète et réussie. L’onglet ROLLBACK (rouge) simule une transaction interrompue par une erreur. L’onglet SAVEPOINT (orange) simule une annulation partielle grâce à un point de sauvegarde intermédiaire. À chaque étape, la requête SQL active est mise en surbrillance, et une grille côte à côte compare l’état de la table avant la transaction et l’état temporaire en mémoire.

La bannière affichée en haut du tableau à chaque étape résume l’état courant de la transaction : 

• 🔓 Transaction ouverte, 
• ⏳ Modifications temporaires,
• ✅ COMMIT 
• ↩️ ROLLBACK.

Ce retour visuel est central : il matérialise le fait que les modifications en cours de transaction ne sont pas encore visibles par les autres sessions connectées à la base.

Scénario COMMIT : validation en 5 étapes

Le scénario COMMIT enchaîne trois opérations dans une même transaction : un débit de 500 sur le compte d’Alice (UPDATE), un crédit de 500 sur le compte de Bob (UPDATE), et l’insertion d’un nouveau compte pour Emma (INSERT). L’outil affiche à chaque étape deux tables côte à côte : l’état original à gauche, l’état en mémoire à droite avec les lignes modifiées en bleu et la ligne insérée en vert italique.

L’étape finale COMMIT consolide toutes les modifications. Les lignes validées passent en vert foncé dans la table de résultat, indiquant qu’elles sont désormais persistées et visibles par toutes les sessions. Sans ce COMMIT, une coupure de session à n’importe quelle étape intermédiaire aurait produit le même effet qu’un ROLLBACK : aucune modification ne serait conservée.

BEGIN;
  UPDATE comptes SET solde = solde - 500 WHERE id = 1; -- Alice : 3000 → 2500
  UPDATE comptes SET solde = solde + 500 WHERE id = 2; -- Bob   : 1500 → 2000
  INSERT INTO comptes VALUES (5, 'Emma', 1000);
COMMIT; -- Les 3 opérations sont persistées ensemble

Scénario ROLLBACK : annulation complète en 5 étapes

Le scénario ROLLBACK reprend les mêmes deux UPDATE sur Alice et Bob, mais une erreur est détectée après le deuxième UPDATE (contrainte violée ou logique applicative). L’étape d’erreur affiche les lignes en cours de modification barrées en rouge, signalant qu’elles vont être annulées. L’étape ROLLBACK finale ramène la table exactement à son état d’avant le BEGIN : les soldes d’Alice et de Bob retrouvent leurs valeurs d’origine, et les lignes concernées sont affichées en gris italique pour matérialiser le retour en arrière.

Ce scénario illustre la propriété la plus protectrice des transactions : aucune modification partielle n’est jamais persistée. Si les deux UPDATE avaient été exécutés sans transaction, l’erreur sur la deuxième opération aurait laissé le débit d’Alice appliqué sans que le crédit de Bob ne soit enregistré, corrompant définitivement les soldes.

BEGIN;
  UPDATE comptes SET solde = solde - 500 WHERE id = 1; -- Alice débitée
  UPDATE comptes SET solde = solde + 500 WHERE id = 2; -- Bob crédité
  -- ⚠️ Erreur détectée (contrainte violée, logique applicative…)
ROLLBACK; -- Les deux UPDATE sont annulés, la table est intacte

Scénario SAVEPOINT : annulation partielle en 7 étapes

Le SAVEPOINT est la mécanique la plus avancée des trois. Il permet de poser un point de repère nommé à l’intérieur d’une transaction encore ouverte, et d’y revenir en cas d’erreur sans annuler l’intégralité des opérations précédentes. L’outil pose le savepoint avant_insert après le UPDATE d’Alice mais avant l’INSERT d’Emma. Quand l’INSERT échoue, seule cette dernière opération est annulée via ROLLBACK TO SAVEPOINT avant_insert.

La transaction reste ouverte après le ROLLBACK TO SAVEPOINT. Le COMMIT final ne valide que le UPDATE d’Alice (effectué avant le savepoint), tandis que l’INSERT d’Emma est définitivement abandonné. L’état final montre uniquement le solde d’Alice modifié, en vert, avec les autres lignes inchangées. Ce comportement est impossible à obtenir avec un simple ROLLBACK, qui aurait tout annulé y compris le UPDATE.

BEGIN;
  UPDATE comptes SET solde = solde - 500 WHERE id = 1; -- Alice débitée
  SAVEPOINT avant_insert;                               -- Point de repère posé
  INSERT INTO comptes VALUES (5, 'Emma', 1000);         -- Tentative d'insertion
  -- ⚠️ Erreur sur l'INSERT
  ROLLBACK TO SAVEPOINT avant_insert; -- Seul l'INSERT est annulé
COMMIT; -- Seul le UPDATE d'Alice est persisté