ACID en pratique

Prérequis (cursus dev) : index et transactions.

Pourquoi

ACID n'est pas un slogan : c'est le contrat qui permet de ne pas vérifier chaque écriture à la main. Comprendre chaque lettre, c'est savoir ce qu'on perd quand on s'en écarte (et quand c'est acceptable).

Concepts

• Atomicité : tout ou rien (virement débité ET crédité, jamais l'un sans l'autre). En pratique : une transaction, un COMMIT/ROLLBACK.
• Cohérence : les règles tiennent (contraintes, clés étrangères, CHECK). La base refuse l'incohérent — mieux que 1000 validations applicatives.
• Isolation : les transactions concurrentes ne se voient pas à moitié (niveaux au cours suivant).
• Durabilité : committé = survit au crash (WAL — journal d'écriture rejoué au redémarrage). synchronous_commit=off = plus vite, moins sûr : à connaître, pas à activer par défaut.

Exemple : le virement qui ne perd rien

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;  -- les deux ou rien, même si le serveur meurt entre les deux

Cas réel

Débit + crédit en deux requêtes séparées « parce que l'ORM le fait comme ça » : crash entre les deux = 100 € créés ex nihilo, découverts à l'audit 6 mois plus tard. Une transaction : incident impossible par construction.

Pièges

• Logique « transactionnelle » en applicatif (vérifier puis écrire) : race condition garantie sous concurrence — la base fait ça mieux (contraintes + transactions).
• Oublier la contrainte en base « l'app vérifie » : l'app change, les imports directs non. La base est le dernier rempart.
• Transactions géantes (import de 1M de lignes en une) : verrous longs + rollback monstrueux. Découper en lots committés.

À retenir

Une transaction par unité métier, contraintes en base (dernier rempart), lots pour le volume.