DELETE CASCADE vs RESTRICT

1. Pourquoi plusieurs options ON DELETE ?

Lorsqu’on définit une clé étrangère (FOREIGN KEY) dans une base de données relationnelle, il faut décider ce qui se passe quand la ligne parent est supprimée. Les concepteurs SQL ont prévu plusieurs comportements, car chaque situation métier est différente.

Tableau visuel des 4 comportements (assisté par Nano Banana 2)

2. Panorama des options ON DELETE

3. CASCADE : suppression automatique

CREATE TABLE commandes (
    id INT PRIMARY KEY,
    client_id INT,
    FOREIGN KEY (client_id) REFERENCES clients(id)
        ON DELETE CASCADE
);

Comportement : Supprimer un client → toutes ses commandes disparaissent.

Quand l’utiliser :

• Les commandes n’ont aucun sens sans leur client.
• Vous voulez automatiser le nettoyage des données orphelines.
• Pas de besoin de conservation historique.

4. RESTRICT : blocage sécuritaire

CREATE TABLE commandes (
    id INT PRIMARY KEY,
    client_id INT,
    FOREIGN KEY (client_id) REFERENCES clients(id)
        ON DELETE RESTRICT
);

Comportement : Supprimer un client qui a des commandes → erreur et blocage.

Quand l’utiliser :

• Vous ne voulez pas perdre les données enfants.
• Vous préférez supprimer manuellement les enfants d’abord.
• L’intégrité référentielle est critique.

5. SET NULL : conservation avec rupture du lien

CREATE TABLE commandes (
    id INT PRIMARY KEY,
    client_id INT,  -- doit accepter NULL !
    FOREIGN KEY (client_id) REFERENCES clients(id)
        ON DELETE SET NULL
);

Comportement : Supprimer un client → ses commandes restent, mais client_id devient NULL.

Quand l’utiliser :

• Vous voulez conserver l’historique des commandes.
• Le lien avec le client n’est plus nécessaire après suppression.
• La colonne enfant accepte NULL.

Illustration du comportement SET NULL (assisté par Nano Banana 2)

6. Comparatif direct CASCADE vs RESTRICT

7. Comment choisir la bonne option ? (arbre de décision)

8. Exemples concrets par cas d’usage

Cas 1 : Site e-commerce (commandes et clients)

-- Conservation obligatoire des commandes (facturation)
ALTER TABLE commandes
ADD CONSTRAINT fk_commandes_client
FOREIGN KEY (client_id) REFERENCES clients(id)
ON DELETE SET NULL;  -- ou RESTRICT selon politique RGPD

Cas 2 : Logs d’application (logs et utilisateurs)

-- Les logs sans utilisateur n'ont pas d'intérêt
ALTER TABLE logs
ADD CONSTRAINT fk_logs_user
FOREIGN KEY (user_id) REFERENCES users(id)
ON DELETE CASCADE;

Cas 3 : Facturation légale (factures et clients)

-- Obligation légale de conservation (interdiction de supprimer)
ALTER TABLE factures
ADD CONSTRAINT fk_factures_client
FOREIGN KEY (client_id) REFERENCES clients(id)
ON DELETE RESTRICT;

9. Particularités selon les SGBD

MySQL / MariaDB

• Seul InnoDB supporte les clés étrangères (MyISAM les ignore).
• RESTRICT et NO ACTION sont équivalents.
• SET DEFAULT est accepté syntaxiquement mais souvent ignoré.

PostgreSQL

• Support complet de toutes les options.
• NO ACTION diffère de RESTRICT : vérification en fin de transaction.
• SET DEFAULT fonctionne si la colonne a une valeur par défaut.

SQL Server

• Support de CASCADE, SET NULL, SET DEFAULT, NO ACTION.
• RESTRICT n’existe pas → utiliser NO ACTION.
• Création via GUI SSMS ou script ALTER TABLE.

11. Conclusion

Le choix entre CASCADE, RESTRICT, SET NULL ou SET DEFAULT n’est pas anodin. Il reflète votre stratégie de gestion des données et doit être aligné avec vos besoins métier.

12. Articles connexes