Rendez vos écritures atomiques avec les transactions et comprenez ce que les garanties ACID impliquent au quotidien.
Ouvrir cette leçon dans KodokonUn virement bancaire, c'est deux UPDATE : débiter un compte, créditer l'autre. Si le second échoue, la base ment. La transaction rend le bloc indivisible, avec les garanties ACID : Atomicité (tout ou rien), Cohérence (les contraintes restent vraies), Isolation (les transactions concurrentes ne se voient pas à moitié faites), Durabilité (un COMMIT survit à un crash). Pour cette leçon, préférez le vrai client sqlite3 : certains bacs à sable web valident chaque requête automatiquement.
CREATE TABLE accounts (
id INTEGER PRIMARY KEY,
owner TEXT NOT NULL,
balance REAL NOT NULL CHECK (balance >= 0)
);
INSERT INTO accounts (owner, balance)
VALUES
('alice', 500.0),
('bruno', 120.0);Le cas nominal : BEGIN ouvre la transaction, les écritures s'accumulent, COMMIT les rend définitives d'un bloc. Entre les deux, aucune autre connexion ne voit l'état intermédiaire (alice débitée, bruno pas encore crédité).
BEGIN;
UPDATE accounts
SET balance = balance - 200
WHERE owner = 'alice';
UPDATE accounts
SET balance = balance + 200
WHERE owner = 'bruno';
COMMIT;
SELECT owner, balance FROM accounts;Le cas d'échec, maintenant. Débiter bruno de 400 violerait CHECK (balance >= 0) : la requête échoue. Subtilité SQLite : par défaut, une erreur annule la requête fautive mais laisse la transaction ouverte. C'est à votre code applicatif de décider : ROLLBACK pour tout annuler (le réflexe sain), ou continuer si l'erreur est récupérable.
BEGIN;
UPDATE accounts
SET balance = balance - 400
WHERE owner = 'bruno';
-- Erreur : CHECK (balance >= 0) rejette la ligne.
ROLLBACK;
SELECT owner, balance FROM accounts;