Modifier les données

Le problème : une base n'est pas figée

Lire des données, c'est 80 % du travail. Mais il faut bien que ces données arrivent quelque part : un nouveau client s'inscrit, change d'email, supprime son compte. Trois actions, trois commandes : INSERT, UPDATE, DELETE.

Ce sont les commandes les plus dangereuses du SQL. Une erreur de lecture renvoie un mauvais résultat ; une erreur d'écriture détruit des données réelles. On reste sur la table clients.

INSERT INTO : ajouter une ligne

INSERT INTO crée une nouvelle ligne. On nomme les colonnes, puis on donne les valeurs dans le même ordre :

INSERT INTO clients (nom, email, ville)
VALUES ('Léa Martin', 'lea@exemple.fr', 'Lyon');

On ne fournit pas l'id : il est auto-incrémenté par la base. On peut insérer plusieurs lignes d'un coup :

INSERT INTO clients (nom, email, ville)
VALUES
    ('Karim Benali', 'karim@exemple.fr', 'Dijon'),
    ('Marie Dupont', 'marie@exemple.fr', 'Besançon');

UPDATE et DELETE : le WHERE est vital

UPDATE modifie des lignes existantes. DELETE en supprime. Les deux doivent être accompagnés d'un WHERE qui désigne précisément les lignes visées :

UPDATE clients
SET email = 'nouveau@exemple.fr'
WHERE id = 1;

DELETE FROM clients
WHERE id = 1;

Le WHERE id = 1 garantit qu'on ne touche qu'une seule ligne, celle de l'utilisateur concerné.

La catastrophe du WHERE oublié

Voici l'erreur qui a déjà coûté leur week-end à des milliers de développeurs :

-- CATASTROPHE : pas de WHERE
UPDATE clients SET email = 'test@test.fr';   -- réécrit l'email de TOUS les clients
DELETE FROM clients;                          -- vide la table ENTIÈRE

Filet de sécurité supplémentaire : la transaction. BEGIN ouvre une zone de travail, COMMIT valide les changements, ROLLBACK annule tout si quelque chose a mal tourné, comme un Ctrl+Z sur la base.

BEGIN;
DELETE FROM clients WHERE id = 1;
-- on vérifie le résultat... puis :
COMMIT;   -- ou ROLLBACK; pour tout annuler

Les transactions : tout ou rien

On a entr'aperçu BEGIN et ROLLBACK comme filet de sécurité pour un DELETE risqué. Mais les transactions ont une vocation plus profonde : garantir qu'un ensemble d'opérations réussit en bloc ou n'a jamais eu lieu.

Imaginez un virement bancaire. Deux étapes sont nécessaires : débiter le compte A de 30 euros, puis créditer le compte B de 30 euros. Si le serveur tombe entre les deux, vous avez débité sans créditer : 30 euros ont disparu. C'est exactement le genre de désastre qu'une transaction empêche.

Une transaction regroupe plusieurs instructions en un bloc atomique : soit toutes réussissent et deviennent définitives d'un coup (COMMIT), soit une échoue et tout est annulé comme si rien ne s'était passé (ROLLBACK). La base revient exactement à l'état d'avant le BEGIN.

Rollback : le filet de sécurité. Si on détecte un problème en cours de route, ROLLBACK efface tout proprement :

-- Démonstration ROLLBACK : le solde d'Alice ne change pas
CREATE TABLE comptes (id INTEGER, nom TEXT, solde INTEGER);
INSERT INTO comptes VALUES (1, 'Alice', 100);
INSERT INTO comptes VALUES (2, 'Bob', 50);

BEGIN;
UPDATE comptes SET solde = solde - 30 WHERE id = 1;
ROLLBACK;

SELECT nom, solde FROM comptes;

Alice reste à 100 : le débit a été annulé intégralement.

Commit : valider un virement complet. Quand les deux étapes réussissent, COMMIT les rend définitives ensemble :

-- Démonstration COMMIT : débit + crédit validés en bloc
CREATE TABLE comptes (id INTEGER, nom TEXT, solde INTEGER);
INSERT INTO comptes VALUES (1, 'Alice', 100);
INSERT INTO comptes VALUES (2, 'Bob', 50);

BEGIN;
UPDATE comptes SET solde = solde - 30 WHERE id = 1;
UPDATE comptes SET solde = solde + 30 WHERE id = 2;
COMMIT;

SELECT nom, solde FROM comptes;

Alice passe à 70, Bob à 80 : les 30 euros ont bien transité, aucune étape n'a été laissée à moitié.