Introduction aux transactions : BEGIN, COMMIT, ROLLBACK

Dans notre cours, on va parler des transactions trois fois. Et à chaque fois, on va découvrir un truc nouveau. Là, on va voir les bases des transactions. Et dans la deuxième partie du cours, on va plonger dans les niveaux d’isolation des transactions, et à la toute fin — les subtilités des transactions imbriquées.

C’est quoi une transaction

On commence simple — la définition. Une transaction, c’est un groupe d’actions qui sont exécutées uniquement ensemble. C’est tout.

Du coup, ça veut dire un truc important : si jamais une (n’importe laquelle !) des actions du groupe plante, il faut annuler le résultat de toutes les autres actions et remettre le système dans son état initial.

En SQL, une transaction, c’est un ensemble d’actions (genre insert, update ou delete), qui garantit que soit toutes les opérations à l’intérieur de la transaction se terminent avec succès, soit aucune n’est prise en compte. Ce comportement rend le travail avec les bases de données fiable et cohérent, surtout dans les scénarios critiques comme le traitement des paiements ou la mise à jour de données liées.

Imagine que tu transfères de l’argent entre deux comptes bancaires. Pour simplifier, on a deux opérations qui s’enchaînent :

1. On retire une somme d’un compte.
2. On crédite la même somme sur l’autre compte.

Si jamais ça plante à la toute fin (genre le serveur tombe), c’est super important que aucun utilisateur ne soit perdant. En gros, soit les deux étapes passent (la transaction est validée), soit les deux sont annulées (la transaction est rollback).

Transactions et principes ACID

Les transactions reposent sur les principes ACID, qui nous rappellent quatre caractéristiques clés :

• Atomicity (Atomicité) : tout ou rien. Soit toutes les opérations de la transaction passent, soit tout est annulé.
• Consistency (Cohérence) : les données restent dans un état correct avant et après la transaction.
• Isolation (Isolation) : chaque transaction fonctionne comme si elle était toute seule sur le système.
• Durability (Durabilité) : une fois validées, les données restent, même si le serveur tombe.

Les commandes de base pour gérer les transactions

Allez, on passe à la pratique ! Voilà les trois commandes principales pour gérer les transactions :

1. BEGIN
   Démarre une nouvelle transaction. Toutes les opérations suivantes seront faites dans ce contexte.

2. COMMIT
   Valide les changements. Après cette commande, tout devient permanent.

3. ROLLBACK
   Annule les changements. Si un truc foire, tu peux rollback la transaction et les données restent comme avant.

Syntaxe de base des transactions

La structure simple d’une transaction :

BEGIN; 
-- ici tu mets tes opérations SQL
COMMIT;

Exemple d’utilisation de ROLLBACK :

BEGIN;
-- modification de la table students
UPDATE students
SET grade = grade + 10
WHERE id = 1;

-- Oh ! On s’est rendu compte que c’était une erreur.
ROLLBACK;

Exemple d’utilisation d’une transaction dans un vrai cas

Imaginons qu’on a des tables :

students :

courses :

Supposons qu’on veuille inscrire un étudiant à un cours et mettre à jour sa note moyenne en même temps :

BEGIN;

-- Étape 1 : On ajoute une ligne dans la table "inscriptions aux cours"
INSERT INTO course_enrollments (student_id, course_id)
VALUES (1, 2);

-- Étape 2 : On met à jour la note moyenne de l’étudiant
UPDATE students
SET grade = grade + 5
WHERE id = 1;

COMMIT;

Qu’est-ce qui se passe si le serveur tombe entre la première et la deuxième étape ? Si on n’utilisait pas de transaction, les données seraient incohérentes : l’inscription serait ajoutée, mais la note ne serait pas mise à jour. Mais avec une transaction, soit les deux opérations passent, soit les deux sont annulées.

Gérer les erreurs dans les transactions

Parfois, un truc ne se passe pas comme prévu, et il faut gérer l’erreur proprement. Dans PostgreSQL, la transaction est automatiquement annulée si une erreur arrive.

On va faire exprès de se planter pour voir ce qui se passe. Imagine qu’on a une contrainte d’unicité sur la colonne student_id dans la table course_enrollments. On va essayer d’ajouter une ligne en double :

BEGIN;

INSERT INTO course_enrollments (student_id, course_id)
VALUES (1, 2);

-- FIN DE LA TRANSACTION (pas encore exécuté)
COMMIT;

Si tu ajoutes un étudiant déjà inscrit au cours, il y aura une erreur, et PostgreSQL va automatiquement terminer la transaction avec un rollback.

Utiliser ROLLBACK pour annuler manuellement

Souvent, tu ne peux pas prévoir toutes les erreurs, et tu voudras annuler la transaction si un truc ne va pas :

BEGIN;

-- On ajoute un nouvel étudiant
INSERT INTO students (name, grade)
VALUES ('Omori Sanny', 75);

-- Oups ! On s’est rendu compte qu’on a ajouté l’étudiant par erreur.
ROLLBACK;

Après la commande ROLLBACK, la table reste inchangée — Omori Sanny n’apparaît pas dans students.

Conseils utiles et erreurs courantes

Travailler avec les transactions, c’est plus simple si tu gardes quelques règles en tête :

• Utilise toujours des transactions si ton opération a plus d’une étape, surtout si tu modifies plusieurs tables.
• N’oublie jamais de valider les changements (COMMIT). Sinon, la transaction reste en attente et les données ne changent pas.
• Enveloppe les opérations complexes dans des transactions pour garder la cohérence des données.
• Si tu vois une erreur à n’importe quelle étape, n’hésite pas à utiliser ROLLBACK.

Maintenant que tu sais comment contrôler les opérations avec les transactions, c’est le moment de mettre ça en pratique et de passer à l’étude des transactions pour garantir l’intégrité des données !