Un commentaire sans article associé, une métadonnée pointant vers un contenu supprimé depuis longtemps : dans un modèle relationnel classique, ce genre d’incohérence est justement ce qu’une contrainte de ce type est censée empêcher, en refusant toute écriture qui violerait la référence.
Une absence volontaire dans le cœur de WordPress
C’est un point qui surprend souvent : les tables natives de WordPress (wp_posts, wp_comments, wp_postmeta…) ne déclarent aucune contrainte de ce type, alors même que wp_comments.comment_post_ID référence logiquement wp_posts.ID. Ce choix historique s’explique par la compatibilité avec le moteur MyISAM, qui ne supportait pas ces contraintes, et par la volonté de conserver des suppressions rapides sans vérification en cascade. L’intégrité référentielle est donc assurée au niveau applicatif, par le code PHP de WordPress lui-même, pas par la base.
Rien n’empêche cependant un développeur d’en définir sur ses propres tables personnalisées, à condition d’utiliser le moteur InnoDB.
Exemple
ALTER TABLE wp_commandes
ADD CONSTRAINT fk_client
FOREIGN KEY (client_id) REFERENCES wp_clients(id)
ON DELETE CASCADE;
Pièges fréquents
- Une table créée en MyISAM accepte silencieusement la syntaxe
FOREIGN KEYsans jamais l’appliquer réellement : vérifiez toujours le moteur de stockage avant de compter sur cette contrainte. - Une suppression en cascade mal maîtrisée peut effacer bien plus de données que prévu ; préférez souvent
ON DELETE RESTRICTen environnement de production sensible.