Il y a tant de problèmes avec FOREIGN KEYs qu'on ne sait même pas par ou commencer :@:
-
Les clés externes compliquent la vie, car les définitions des clés externes doivent être enregistrées dans une base de données, et les implémenter nous forcera à abandonner la gestion actuelle des tables (une table égale un fichier, qui peut être sauvé ou copié).
-
L'impact sur la vitesse d'exécution de
INSERT et UPDATE, et dans ce cas, presque toutes les vérifications dues à FOREIGN KEY ne servent à rien, car vous insérez les informations dans le bon ordre, naturellement.
-
Les clés externes imposent l'utilisation de verrous sur de nombreuses tables, et cela peut conduire, par effet de domino, à geler toute la base. Il est beaucoup plus rapide d'effacer un enregistrement d'une table, puis de s'occuper des autres tables à la suite.
-
Avec les clés externes, il n'est plus possible de reconstituer une table par un effacement complet, suivi d'un chargement de tous les enregistrements (depuis une nouvelle source, ou une sauvegarde).
-
Avec les clés externes, il est impossible faire un dump d'une table, puis de la recharger, à moins de le faire dans un ordre très spécifique.
-
Il est très facile de créer des références circulaires, qui sont autorisées, mais rendent impossible la recréation de la table à partir d'un enregistrement unique, même si la définition de la table fonctionne et est utilisable.
Le seul aspect intéressant de FOREIGN KEY est de donner aux clients ODBC et quelques autres la possibilité de voir comment une table est connectée, et de l'utiliser pour créer un diagramme de connexion lors de la création d'applications.
MySQL gérera prochainement les définitions des FOREIGN KEY, ce qui permettra aux clients de réclamer la structure de la connexion originale. La version courantes des fichiers ``.frm'' ne le permet pas.