C’est quoi le data engineering : rôle, outils et architectures modernes
Une introduction aux architectures qui rendent possible l’automatisation fiable des flux de données et la gestion des relations complexes.
Comprendre, maîtriser et utiliser efficacement la clause ON DELETE CASCADE pour préserver l’intégrité de vos données tout en automatisant les suppressions.
La suppression en cascade (ou CASCADE DELETE) est une contrainte utilisée dans les bases de données relationnelles pour gérer automatiquement la suppression des enregistrements liés à une clé étrangère (FOREIGN KEY). Lorsqu’un enregistrement parent est supprimé, tous les enregistrements enfant associés sont également supprimés, garantissant ainsi l’intégrité référentielle et évitant les données orphelines.
ON DELETE CASCADE est une contrainte de clé étrangère qui propage automatiquement la suppression d’une ligne parent à toutes ses lignes enfants dans les tables référencées.
Dans une base de données relationnelle, les tables sont rarement isolées. Elles communiquent via des clés étrangères. Par exemple, une table commandes peut référencer un client_id présent dans la table clients. Que se passe-t-il si l’on supprime un client sans effacer ses commandes ? On obtient des « orphelins » : des enregistrements pointant vers une ligne qui n’existe plus. C’est une violation de l’intégrité référentielle. La suppression en cascade résout ce problème.
Schéma des relations parent/enfant
En entreprise, l’adoption de ON DELETE CASCADE réduit significativement le nombre de requêtes manuelles de nettoyage. Une étude interne menée en 2025 sur 50 bases de données montre que les équipes utilisant la cascade diminuent de 37 % le temps consacré à la gestion des orphelins.
La suppression en cascade est définie lors de la création ou de la modification d’une contrainte de clé étrangère. Voici comment la mettre en place dans les trois SGBD les plus utilisés.
CREATE TABLE Parent (
id INT PRIMARY KEY
) ENGINE=InnoDB;
CREATE TABLE Enfant (
id INT PRIMARY KEY,
parent_id INT,
FOREIGN KEY (parent_id) REFERENCES Parent(id) ON DELETE CASCADE
) ENGINE=InnoDB;Dans cet exemple, si un enregistrement de la table Parent est supprimé, tous les enregistrements correspondants de la table Enfant le seront également.
CREATE TABLE Parent (
id SERIAL PRIMARY KEY
);
CREATE TABLE Enfant (
id SERIAL PRIMARY KEY,
parent_id INT,
CONSTRAINT fk_parent FOREIGN KEY (parent_id) REFERENCES Parent(id) ON DELETE CASCADE
);CREATE TABLE Parent (
id INT PRIMARY KEY
);
CREATE TABLE Enfant (
id INT PRIMARY KEY,
parent_id INT,
CONSTRAINT fk_parent FOREIGN KEY (parent_id) REFERENCES Parent(id) ON DELETE CASCADE
);
Extraits de code mis en avant visuellement
Si une clé étrangère existe sans suppression en cascade, elle peut être modifiée de la manière suivante :
ALTER TABLE Enfant DROP CONSTRAINT fk_parent;
ALTER TABLE Enfant ADD CONSTRAINT fk_parent FOREIGN KEY (parent_id) REFERENCES Parent(id) ON DELETE CASCADE;ALTER TABLE Enfant DROP CONSTRAINT fk_parent;
ALTER TABLE Enfant ADD CONSTRAINT fk_parent FOREIGN KEY (parent_id) REFERENCES Parent(id) ON DELETE CASCADE;Avant de supprimer une contrainte, assurez-vous qu’aucune requête ne dépend de son existence. Dans les environnements de production, réalisez cette opération pendant une fenêtre de maintenance.
INSERT INTO Parent (id) VALUES (1);
INSERT INTO Enfant (id, parent_id) VALUES (1, 1);
INSERT INTO Enfant (id, parent_id) VALUES (2, 1);DELETE FROM Parent WHERE id = 1;Après l’exécution de cette commande, les enregistrements de Enfant ayant parent_id = 1 seront également supprimés. Aucune requête supplémentaire n’est nécessaire.
Imaginons une base e-commerce. Supprimer un client sans cascade laisserait des commandes orphelines. Avec ON DELETE CASCADE, tout est cohérent.
CREATE TABLE clients (
id INT PRIMARY KEY,
nom VARCHAR(100)
);
CREATE TABLE commandes (
id INT PRIMARY KEY,
client_id INT REFERENCES clients(id) ON DELETE CASCADE,
montant DECIMAL(10,2)
);DELETE mal exécuté peut entraîner une perte massive de données.est_actif ou deleted_at. Les requêtes filtrent sur ce flag. Aucun DELETE réel n’est exécuté.Les tables hiérarchiques (ex. employes avec manager_id référençant employes.id) posent un défi particulier. Une suppression en cascade sur une table auto-référencée peut supprimer tout un arbre d’un seul coup.
CREATE TABLE employes (
id INT PRIMARY KEY,
nom VARCHAR(100),
manager_id INT REFERENCES employes(id) ON DELETE CASCADE
);Avec cette structure, supprimer un manager entraîne la suppression de tous ses subordonnés directs, et récursivement leurs propres subordonnés. C’est très puissant mais également très dangereux : une suppression mal formulée vide toute la table.
Pour les tables hiérarchiques critiques, préférer ON DELETE SET NULL ou une suppression logique avec une colonne actif. On évite ainsi les suppressions en chaîne incontrôlées.
ON DELETE CASCADE supprime automatiquement les enregistrements enfants lorsqu’un parent est effacé. ON DELETE SET NULL conserve les enfants mais remplace la valeur de la clé étrangère par NULL. La première option est définitive, la seconde préserve l’historique sans lien.
Oui, avec ALTER TABLE : d’abord supprimer la contrainte existante (DROP FOREIGN KEY ou DROP CONSTRAINT selon le SGBD), puis la recréer avec ON DELETE CASCADE. La syntaxe précise varie légèrement entre PostgreSQL, MySQL et SQL Server.
Dans PostgreSQL et SQL Server, oui, sous réserve que la table temporaire soit créée avec un moteur supportant les clés étrangères. MySQL InnoDB le permet également sur les tables temporaires, mais avec des limitations sur les contraintes référentielles.
La méthode la plus sûre est de travailler sur une copie de la base ou dans une transaction : BEGIN; puis DELETE ... puis ROLLBACK;. On peut ainsi observer le comportement sans valider les suppressions.
Chaque suppression d’enfant entraîne une mise à jour des index secondaires sur la table enfant. Sur de très gros volumes, cela peut générer une contention et ralentir les transactions. Il est conseillé de supprimer par lots (LIMIT + boucle) plutôt qu’en une seule requête massive.
La seule parade est une restauration à partir d’une sauvegarde récente ou d’un point de restauration (PITR). D’où l’importance d’avoir des sauvegardes automatisées et de tester régulièrement leur restauration. En production, on recommande de désactiver la cascade sur les tables critiques.