On en a déjà parlé plus tôt dans le cours, c’est quoi une transaction. Petit rappel : c’est une séquence d’opérations qui doit s’exécuter comme un tout. Genre, tu dois faire un virement bancaire. Là, tu retires de l’argent d’un compte et tu le mets sur un autre. Si une de ces actions foire (genre l’argent est débité mais pas crédité), c’est la galère. C’est là que les transactions sauvent la mise.
Une transaction va soit s’exécuter entièrement, soit pas du tout. C’est ce qu’on appelle le principe du "tout ou rien".
BEGIN;
-- On diminue le solde sur un compte
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;
-- On augmente le solde sur l’autre compte
UPDATE accounts SET balance = balance + 100 WHERE account_id = 2;
COMMIT; -- On valide les changements
Si un truc tourne mal, tu peux annuler les modifs avec ROLLBACK.
C’est quoi les propriétés ACID des transactions
Quand on parle de transactions dans PostgreSQL (et dans les bases relationnelles en général), on entend souvent le sigle ACID — rien à voir avec la chimie. ACID, ça veut dire Atomicity (atomicité), Consistency (cohérence), Isolation (isolation), Durability (durabilité). Ces quatre propriétés garantissent que les données sont traitées de façon safe, cohérente et sans surprises.
Atomicité (Atomicity)
La transaction s’exécute en entier ou pas du tout. Si un truc foire à l’intérieur — tout est annulé. Imagine : tu fais un virement, et paf, erreur — soit tout est annulé, soit le virement passe à 100%. Pas de demi-mesure.
Cohérence (Consistency)
Après la transaction, la base reste dans un état correct, logique. Toutes les règles, contraintes et liens entre les tables doivent être respectés. Par exemple, si t’as pas le droit d’avoir un solde négatif, une transaction qui viole ça ne sera juste pas enregistrée.
Isolation (Isolation)
Tant qu’une transaction n’est pas finie, une autre ne doit pas voir ses données intermédiaires. Ça évite les effets chelous où tu vois un état « indéfini » des données. Imagine, dans un shop en ligne, l’argent est déjà débité mais le produit n’est pas encore ajouté à la commande — pas cool, hein ?
Durabilité (Durability)
Si la transaction s’est terminée avec succès, tous ses changements sont garantis d’être sauvegardés. Même si juste après, y’a une coupure de courant — les données restent dans la base. C’est comme cliquer sur "Enregistrer" et être sûr que tout est bien là.
Voilà, ces quatre propriétés, c’est la base de pourquoi les transactions sont un mécanisme fiable pour bosser avec les bases de données.
Exemples de scénarios où les transactions sont utiles
La théorie, c’est cool, mais la vraie force des transactions, c’est dans les cas concrets. C’est dans ces situations — avec de l’argent, des tables liées ou des modifs en masse — que les transactions deviennent indispensables. Elles permettent pas juste de faire des opérations, mais de le faire sereinement, sans risque de perdre des données ou de laisser la base dans un état « à moitié cassé ».
Voilà quelques exemples typiques où les transactions sauvent vraiment la mise :
1. Gestion des paiements
Quand un client transfère de l’argent d’un compte à un autre, la transaction garantit que l’argent ne disparaît pas dans la nature :
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;
UPDATE accounts SET balance = balance + 100 WHERE account_id = 2;
COMMIT;
Si le premier compte n’a pas assez de sous, tu peux annuler les changements :
BEGIN;
UPDATE accounts SET balance = balance - 500 WHERE account_id = 1;
-- Oups, solde négatif !
ROLLBACK;
2. Mise à jour de tables liées
Imagine que tu mets à jour le statut d’un étudiant en "diplômé" et que tu ajoutes en même temps une ligne dans la table "diplômés" :
BEGIN;
UPDATE students SET status = 'gradué' WHERE student_id = 42;
INSERT INTO graduates (student_id, graduation_date) VALUES (42, '2023-06-10');
COMMIT;
Si une des opérations foire (genre une erreur dans INSERT), la base revient à l’état initial.
3. Mise à jour massive de données
Les transactions sont super utiles pour faire de grosses mises à jour, par exemple :
BEGIN;
UPDATE orders SET status = 'terminée' WHERE delivery_date < CURRENT_DATE;
COMMIT;
Si le serveur plante ou si tu vois que la mise à jour part en vrille, tu peux annuler les changements à tout moment !
Commandes pour bosser avec les transactions
PostgreSQL propose quelques commandes clés :
BEGIN: démarre une nouvelle transaction :BEGIN;COMMIT: valide (sauvegarde) tous les changements faits dans la transaction :COMMIT;
ROLLBACK : annule tous les changements faits dans la transaction en cours :
ROLLBACK;
Exemple de cycle complet
BEGIN;
-- Quelques opérations
UPDATE accounts SET balance = balance - 200 WHERE account_id = 1;
UPDATE accounts SET balance = balance + 200 WHERE account_id = 2;
-- On décide d’annuler les changements
ROLLBACK;
-- On recommence
BEGIN;
-- Les mêmes opérations, mais un autre transfert
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;
UPDATE accounts SET balance = balance + 100 WHERE account_id = 2;
-- On termine la transaction
COMMIT;La vie des transactions hors du manuel
Shops en ligne. Beaucoup de plateformes utilisent les transactions pour gérer les commandes et les paiements. Par exemple, une commande n’est validée que si le paiement passe. Si un truc foire, la commande est automatiquement annulée.
Systèmes bancaires. Les transactions protègent ton argent contre les soucis genre coupure de courant inattendue.
Historique des transactions. PostgreSQL garde des journaux WAL (Write-Ahead Logging) pour restaurer les données en cas de crash. C’est la magie qui rend les transactions fiables.
Dans la prochaine leçon, on va détailler les commandes BEGIN, COMMIT et ROLLBACK, et on va voir des exemples d’opérations en masse et de rollback partiel avec SAVEPOINT. À bientôt !
GO TO FULL VERSION