Est-ce que COMMIT est automatique en SQL ?

Cela dépend du mode "autocommit" du SGBD. Souvent, il est activé par défaut, ce qui signifie que chaque commande SQL est traitée comme une mini-transaction et validée immédiatement. Pour des transactions complexes, il faut désactiver l'autocommit et utiliser explicitement BEGIN, COMMIT et ROLLBACK.

Quelle est la différence entre ROLLBACK et un simple DELETE pour annuler ?

Un DELETE est une opération de données comme une autre, qui sera elle-même validée ou annulée. ROLLBACK est une commande de contrôle qui annule *toutes* les modifications temporaires depuis le début de la transaction, qu'il s'agisse d'INSERT, UPDATE ou DELETE. C'est un retour en arrière global et garanti.

Les propriétés ACID s'appliquent-elles à toutes les bases de données ?

Non, c'est une caractéristique principale des bases de données relationnelles (SQL) comme PostgreSQL, MySQL ou SQLite. Beaucoup de bases de données NoSQL (comme MongoDB) privilégient la performance et la scalabilité à la stricte conformité ACID, offrant parfois un modèle "BASE" (Basically Available, Soft state, Eventually consistent).

Les transactions SQL et la propriete ACID

Introduction : Pourquoi les transactions sont-elles indispensables ?

Imagine que tu doives virer 50€ de ton compte épargne vers ton compte courant. En SQL, cela implique deux opérations : soustraire 50€ d'un compte et ajouter 50€ à l'autre. Si la première opération réussit mais que la seconde échoue à cause d'une panne, l'argent disparaîtrait purement et simplement ! C'est pour éviter ce genre de scénario catastrophe que les transactions SQL existent. Elles permettent de regrouper plusieurs instructions en une seule unité logique de travail qui doit soit totalement réussir, soit totalement échouer. C'est le cœur de la fiabilité des bases de données que tu étudies en NSI.

Qu'est-ce qu'une transaction SQL ?

Une transaction est une séquence d'opérations sur une base de données (comme des INSERT, UPDATE, DELETE) traitée comme une unité indivisible. On la compare souvent à une boîte noire : de l'extérieur, on ne voit que son état avant et après son exécution, jamais les étapes intermédiaires.

Pour gérer une transaction, on utilise trois commandes principales :

BEGIN TRANSACTION ou simplement BEGIN : Marque le début de la transaction.
COMMIT : Valide définitivement toutes les modifications effectuées depuis le BEGIN. C'est le "tout est bon, sauvegarde !".
ROLLBACK : Annule toutes les modifications effectuées depuis le BEGIN. C'est le "il y a un problème, on revient à l'état initial".

Voici un exemple concret avec notre virement :

BEGIN TRANSACTION; UPDATE Comptes SET solde = solde - 50 WHERE id = 'Epargne'; UPDATE Comptes SET solde = solde + 50 WHERE id = 'Courant'; -- Si on arrive ici sans erreur : COMMIT; -- Si une erreur survient (ex: solde insuffisant) : -- ROLLBACK;

Les 4 piliers ACID : Le garant de l'intégrité

ACID est un acronyme qui décrit les propriétés fondamentales d'une transaction fiable. C'est un concept clé à maîtriser pour ton épreuve de NSI.

Atomicité (A)

La transaction est indivisible (comme un atome). Soit toutes ses opérations sont exécutées, soit aucune ne l'est. Il n'y a pas d'état intermédiaire visible. C'est le rôle du COMMIT (tout valider) et du ROLLBACK (tout annuler) que nous avons vu.

Cohérence (C)

Une transaction doit faire passer la base de données d'un état cohérent à un autre état cohérent. Elle respecte toutes les règles définies : contraintes d'intégrité (PRIMARY KEY, FOREIGN KEY), triggers, etc. Par exemple, une transaction ne pourra pas créer une commande liée à un client qui n'existe pas.

Isolation (I)

Les transactions exécutées concurrentiellement (en même temps) ne doivent pas s'interférer. Le résultat de l'exécution simultanée de plusieurs transactions doit être le même que si elles avaient été exécutées les unes après les autres, dans un ordre sérialisé. Cela évite des problèmes comme la "lecture sale" (lire des données non encore validées).

Durabilité (D)

Une fois qu'une transaction est validée (COMMIT), ses modifications sont définitives et persistantes, même en cas de panne du système (coupure de courant, crash). Les données sont écrites sur un support de stockage permanent.

Exemples pratiques et pièges courants en NSI

Voyons comment utiliser cela dans un projet. Prenons l'exemple d'un système d'inscription à un événement qui doit décrémenter le nombre de places et ajouter un participant.

BEGIN; -- 1. Vérifier et décrémenter les places disponibles UPDATE Evenements SET places_restantes = places_restantes - 1 WHERE id = 100 AND places_restantes > 0; -- 2. Si la mise à jour a affecté une ligne (place disponible), ajouter le participant INSERT INTO Participants (evenement_id, nom_eleve) VALUES (100, 'Emma'); -- Si tout est OK : COMMIT; -- Sinon (pas de place ou autre erreur) : -- ROLLBACK;

Piège à éviter : Oublier de gérer l'isolation. Si deux utilisateurs tentent de s'inscrire à la dernière place en même temps, sans bonne isolation, tu pourrais avoir deux inscriptions pour une seule place ! Les SGBD (Systèmes de Gestion de Base de Données) comme PostgreSQL ou MySQL offrent différents niveaux d'isolation (READ COMMITTED, REPEATABLE READ, etc.) pour contrôler cela.

Conclusion : Un outil puissant pour des projets solides

Maîtriser les transactions et ACID n'est pas qu'une question de cours pour le Bac NSI. C'est une compétence essentielle pour concevoir des applications robustes. Que tu développes un site de e-commerce, une application de gestion ou un jeu multi-joueurs, toute action critique modifiant les données doit être encapsulée dans une transaction. Cela garantit que tes données restent fiables et cohérentes, quelles que soient les pannes ou les actions concurrentes des utilisateurs. Alors, la prochaine fois que tu écris un script Python avec SQL, pense ACID !