Dernier rappel du chapitre 6 : une transaction garantit que la création d'un ticket et de sa livraison s'appliquent ensemble.

BEGIN;

INSERT INTO tickets (plat_id, quantite, semaine)
VALUES (2, 1, 'cette_semaine');

INSERT INTO expeditions (id, transporteur, statut)
VALUES (8, 'Rapido', 'en_cours');

COMMIT;

Les deux INSERT appartiennent à la même transaction : soit les deux réussissent ensemble au COMMIT, soit un ROLLBACK les annule tous les deux. Sans cette transaction commune, un échec du second INSERT (par exemple un id de livraison déjà utilisé) laisserait le premier INSERT appliqué — un ticket sans jamais aucune indication de livraison prévue, ni de statut « sur place » explicite.

À retenir :

• Une transaction reste le bon outil dès que deux écritures liées (une commande et sa livraison) doivent réussir ou échouer ensemble.
• C'est la même garantie, appliquée au même schéma commande/livraison, que celle vue dès le chapitre 6 sur les abonnés et leurs inscriptions.

À vous de jouer : si le second INSERT de cette transaction échouait avant le COMMIT, le ticket créé par le premier INSERT existerait-il malgré tout dans la base, après un ROLLBACK ?