Ce cas pratique combine transaction, sous-requête et vérification — les notions de ce chapitre.

BEGIN;

UPDATE abonnes
SET statut = 'inactif'
WHERE id IN (
  SELECT abonne_id FROM inscriptions WHERE date_debut < '2023-01-01'
);

SELECT id, statut FROM abonnes WHERE statut = 'inactif';

COMMIT;

Étape par étape :

1. BEGIN ouvre une transaction : rien n'est encore définitif.
2. UPDATE modifie les abonnés ciblés par la sous-requête, mais reste provisoire.
3. Le SELECT intermédiaire vérifie le résultat, toujours à l'intérieur de la transaction, sans rien valider.
4. COMMIT rend l'UPDATE définitif, seulement une fois la vérification jugée satisfaisante.

Si le SELECT de vérification révélait un résultat inattendu (trop, ou trop peu de lignes concernées), ROLLBACK annulerait l'UPDATE avant qu'il ne devienne définitif — la transaction n'aurait alors eu aucun effet.

À retenir :

• Une transaction peut inclure un SELECT de vérification entre une modification et sa validation, sans casser l'atomicité de l'ensemble.
• COMMIT ne doit être exécuté qu'après avoir vérifié que la modification correspond bien à l'intention initiale.
• Cette séquence (modifier, vérifier, valider ou annuler) est une pratique de sécurité courante avant toute opération d'écriture sensible.

À vous de jouer : si le SELECT de vérification affichait un abonné qui n'aurait pas dû être concerné, quelle instruction remplacerait COMMIT pour tout annuler ?