SCENE 4 : Modification des Données - Les Aveux et les Effacements

L'interrogatoire est terminé. Maintenant, on agit. On insère, on modifie, on efface. Les mains dans la pâte. Le stylo sur le registre. La gomme sur le papier.

✏️ Modification : INSERT, UPDATE, DELETE

Jusqu'ici, on a regardé. Maintenant, on touche.
Trois commandes. Trois façons de changer l'histoire.
Attention : Un WHERE oublié, et c'est toute la ville qui part en fumée.

INSERT – Faire Entrer un Nouveau Joueur

On ouvre la porte. On fait entrer un nouveau nom dans le système.
Une nouvelle ligne dans la table. Une nouvelle ombre sur le mur.

Syntaxe propre, précise :

INSERT INTO client (nom, prenom, email, ville)
VALUES ('Morand', 'Jean', 'jean.morand@ombre.net', 'Grenoble');

On dit où on met les données. Dans quelles colonnes.
L'id ? Il se génère tout seul. BIGSERIAL. Comme un numéro de dossier qui tombe du ciel.

Syntaxe paresseuse, dangereuse :

INSERT INTO client
VALUES (DEFAULT, 'Morand', 'Jean', 'jean.morand@ombre.net', 'Grenoble', CURRENT_DATE);

Il faut tout donner. Dans l'ordre. Comme réciter son alibi sous la lampe.
Un jour, la table changera. Et cette requête se brisera.

Insérer plusieurs d'un coup :

INSERT INTO produit (nom, categorie, prix)
VALUES
    ('Revolver .38', 'Armement', 450),
    ('Lampe torche', 'Équipement', 25),
    ('Manteau trench', 'Vêtement', 120);

Une rafale. Plus efficace que trois coups isolés.

Insérer depuis un SELECT : La copie d'écran.

-- Mettre les vieux clients aux archives
INSERT INTO client_archive (client_id, nom, prenom)
SELECT client_id, nom, prenom
FROM client
WHERE date_inscription < '2020-01-01';
-- Ceux qui ont disparu. Ou qu'on veut faire disparaître.

UPDATE – Réécrire l'Histoire

On change une valeur. Un détail. Une date. Un prix.
La clause WHERE est le pistolet sur la tempe. Sans elle, on tire à bout portant sur toute la table.

Syntaxe :

UPDATE table
SET colonne = nouvelle_valeur
WHERE condition; -- La condition. La seule chose qui vous sépare du chaos.

Exemples :

-- Changer l'email d'un type précis
UPDATE client
SET email = 'nouveau@cache.fr'
WHERE client_id = 42; -- L'id. La seule vérité.

-- Augmenter tous les prix d'une catégorie
UPDATE produit
SET prix = prix * 1.10
WHERE categorie = 'Armement'; -- L'inflation. Toujours l'inflation.

-- Mettre à jour depuis une sous-requête. Les ramifications.
UPDATE commande
SET statut = 'Expédiée', date_expedition = CURRENT_DATE
WHERE commande_id IN (
    SELECT commande_id
    FROM commande
    WHERE statut = 'En attente'
      AND date_commande < NOW() - INTERVAL '2 days'
);
-- Les commandes qui traînent. On les bouge.

⚠️ LA RÈGLE D'OR ⚠️
Avant un UPDATE, faites un SELECT.
Toujours.

-- Avant de tout mettre à zéro :
-- UPDATE produit SET prix = 0 WHERE categorie = 'Liquidation';
-- Regardez ce que vous allez tuer :
SELECT * FROM produit WHERE categorie = 'Liquidation';

DELETE – Faire Disparaître

Supprimer. Effacer. La gomme. L'acide.
Sans WHERE, c'est un incendie. La table entière part en cendres.

Syntaxe :

DELETE FROM table
WHERE condition; -- La frontière entre un nettoyage et un massacre.

Exemples :

-- Supprimer un client. Une fois.
DELETE FROM client
WHERE client_id = 123;
-- Parfois, on désactive. On met un flag. On ne supprime jamais vraiment.

-- Nettoyer les vieilles commandes annulées
DELETE FROM commande
WHERE statut = 'Annulée'
  AND date_commande < CURRENT_DATE - INTERVAL '1 year';
-- Le temps efface tout. Sauf ce qu'on lui demande d'effacer.

-- Suppression avec jointure (PostgreSQL)
DELETE FROM produit p
USING categorie c
WHERE p.categorie_id = c.categorie_id
  AND c.nom = 'Obsolète';
-- Les produits d'une catégorie morte.

Les clés étrangères jouent leur rôle.
Si quelqu'un référence la ligne que vous voulez supprimer, le SGBD dit non.
Sauf si vous avez mis ON DELETE CASCADE. Alors c'est la tuerie en chaîne.
Réfléchissez-y. Deux fois.

TRUNCATE TABLE – La Plaque à Effacer
Plus rapide. Plus radical. Pas de WHERE. Pas de pitié.

TRUNCATE TABLE logs_temporaires;
-- Tout est parti. Comme un coup de vent.

On l'utilise pour les tables de travail. Les déchets.
Jamais sur les données vives. Jamais sans savoir.

⚠️ Transactions : BEGIN, COMMIT, ROLLBACK

La vie n'est pas une suite d'actions isolées.
C'est une suite d'étapes liées. Un virement. Une commande. Un enregistrement.
Les transactions, c'est le fil qui relie les étapes.
Tout ou rien. C'est la loi.

Pourquoi ?

Un virement bancaire :

1. Débiter le compte A.
2. Créditer le compte B.

Si le premier passe et le second échoue, l'argent s'évapore.
Une transaction dit : soit les deux, soit aucun.
L'atomicité. Pas de demi-mesure.

Les Commandes

• BEGIN – On commence. Le rideau se lève.
  Les modifications qui suivent sont en suspens.
  Personne d'autre ne les voit. Encore.
• COMMIT – On valide. C'est fait. Permanent.
  La lumière se fait. Tout le monde voit.
• ROLLBACK – On annule. Comme si rien ne s'était passé.
  Le rideau tombe. L'effacement.

Exemple :

BEGIN; -- Ça commence.

-- Débiter le compte source
UPDATE comptes
SET solde = solde - 1000
WHERE compte_id = 123;

-- Vérifications...
-- Si quelque chose cloche : ROLLBACK; et on sort.

-- Créditer le compte destination
UPDATE comptes
SET solde = solde + 1000
WHERE compte_id = 456;

-- Tout est bon.
COMMIT; -- Ça devient réel.

Auto-commit : La plupart des clients sont en mode auto-commit.
Chaque commande est une micro-transaction immédiatement validée.
Pour enchaîner, il faut explicitement un BEGIN.

ACID – Les Quatre Piliers de la Confiance

1. Atomicité (Atomicity)
   Tout ou rien. Une unité indivisible.
   Garanti par COMMIT/ROLLBACK.

2. Cohérence (Consistency)
   La transaction fait passer la base d'un état valide à un autre état valide.
   Elle respecte les contraintes. Sinon, ROLLBACK automatique.

3. Isolation (Isolation)
   Les transactions qui tournent en même temps ne se marchent pas sur les pieds.
   Il y a des niveaux. Du plus faible au plus fort :

   • READ UNCOMMITTED – On voit les données sales des autres. Les bribes.
   • READ COMMITTED (défaut PostgreSQL) – On ne voit que ce qui est validé. Propre.
   • REPEATABLE READ (défaut MySQL) – Ce qu'on a lu une fois, on le relit identique.
   • SERIALIZABLE – Comme si tout se passait l'un après l'autre. Lent. Sûr.

4. Durabilité (Durability)
   Une fois COMMIT, c'est gravé dans le marbre.
   Même une panne ne l'efface pas.
   Le journal de transaction (WAL) est votre assurance.

Changer le niveau d'isolation :

BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;
-- Ou
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

Bonnes Pratiques – Les Règles de Survie

1. Transactions courtes.
   Plus c'est long, plus ça bloque les autres. Plus c'est risqué.
2. SELECT avant UPDATE/DELETE.
   Voir ce qu'on va toucher.
3. ROLLBACK pour tester.
   Pendant le dev : BEGIN, test, ROLLBACK. Rien n'est écrit.
4. Comprendre l'isolation.
   READ COMMITTED suffit pour 95% des cas.
   Les autres 5%, c'est la finance. Ou le crime organisé.

Cas concret : Un virement contrôlé

BEGIN;

-- Verrouiller la ligne. Pour être seul à la toucher.
SELECT solde FROM comptes WHERE compte_id = 123 FOR UPDATE;

-- Si solde >= montant...
UPDATE comptes SET solde = solde - 1000 WHERE compte_id = 123;
UPDATE comptes SET solde = solde + 1000 WHERE compte_id = 456;

-- La trace. Toujours une trace.
INSERT INTO audit_virements (de, vers, montant, heure)
VALUES (123, 456, 1000, NOW());

COMMIT;
-- En cas de problème : ROLLBACK. Et on repart à zéro.

Fin des Modifications

Maintenant, vous savez lire et écrire.
SELECT pour observer.
INSERT, UPDATE, DELETE pour agir.
Les transactions pour lier le tout, proprement.

La puissance a un prix.
Un WHERE oublié peut tout effacer.
Une transaction mal fermée peut tout bloquer.

Souvenez-vous :
Les données, c'est comme les gens.
On peut les interroger, les corriger, les faire disparaître.
Mais chaque action a une conséquence.
Et la base de données, elle, se souvient de tout.

Prochaine étape : le DDL.
Créer, modifier, détruire les structures elles-mêmes.
Les tables, les colonnes, les index.
L'architecture de l'ombre.