Dans les bases de données où la vérification de clé étrangère a été désactivée dans le passé, comment peut-on vérifier les violations de contraintes de clé étrangère?Comment rechercher des violations de clé étrangère sur l'ensemble de la base de données? (J'utilise actuellement MySQL)
L'activation de la contrainte de clé étrangère vérifie toutes les relations, donc si quelque chose ne va pas, vous obtiendrez une erreur.
la question a le donné que les contraintes de clé étrangère sont désactivées pour une raison. et les rallumer après que les données soient chargées ne fera pas mysql vérifier les données existantes. Alors, comment cette réponse est-elle utile? – longneck
Veuillez prouver que l'activation des clés étrangères n'échoue pas dans MySQL s'il y a des violations. Si c'était vrai, les clés étrangères seraient inutiles. S'il y a un bogue, utilisez ALTER TABLE pour supprimer les contraintes FK et ajoutez-les: Lorsque vous ajoutez une contrainte FK, le DB * doit * vérifier les données. –
mysql supporte les clés étrangères et les applique. mais il vous permet également de désactiver temporairement l'application de ces clés pour accélérer les importations de données relationnelles. voir http://dev.mysql.com/doc/refman/5.0/en/server-session-variables.html#sysvar_foreign_key_checks – longneck
Il n'existe pas de méthode intégrée pour cela. la seule chose que je peux penser serait de regarder les tables TABLE_CONSTRAINTS et KEY_COLUMN_USAGE dans la base de données INFORMATION_SCHEMA pour vérifier manuellement les lignes qui ne correspondent pas.
"Activer" le FK après la charge devrait en effet déjà faire le contrôle.
Si votre SGBD ne le fait pas, videz-le.
Si votre SGBD ne le fait pas et que vous voulez continuer à travailler avec de telles conneries, vous pouvez faire une requête de l'expression SEMIMINUS appropriée de la RA.
Ceci est susceptible de ressembler à:
SELECT ... DE table_with_FK OU PAS EXISTE ( SELECT ... DE table_with_PK OÙ PK_attribute1 = FK_attribute1 et PK_attribute2 = FK_attribute2 et ... ) ET < quelque chose ici qui vous permet d'identifier les lignes chargées >
ou un peu plus moderne (si votre SGBD prend en charge SAUF):
FK_attributes SELECT DE table_with_FK OÙ < ici quelque chose qui vous permet d'identifier les lignes chargées > SAUF SELECT PK_attributes_possibly_renamed DE table_with_PK ;
EDIT (répondant à « pas tout le monde a besoin d'Oracle et IBM produits de taille. « Dump it » est pas un bon conseil. »)
L'OP a très clairement indiqué qu'il est certainement intéressé par l'intégrité des données. Donc, il devrait vraiment utiliser un produit SGBD qui offre un peu de soutien de niveau professionnel pour assurer l'intégrité des données. J'espère sincèrement que "Oracle et les produits IBM" ne sont pas les seuls à le faire.
tout le monde n'a pas besoin d'oracle et de produits de taille IBM. "vider" n'est pas un bon conseil. – longneck
@longneck: Il y a plus de produits SGBD qu'Oracle et IBM. En fait, étant donné que l'utilisateur utilise déjà MySQL, je pense que PostgreSQL ™ serait le prochain choix logique s'il jetait MySQL. – Powerlord
Il me semble que vous pourriez fondamentalement reformuler votre question comme "Comment puis-je assurer l'intégrité référentielle avec des clés étrangères désactivées?" J'imagine que les "maux de tête" qui vous ont fait désactiver les clés étrangères sont exactement ce qu'ils étaient destinés à faire appliquer. Donc, la réponse la plus simple à moi semble ne pas les désactiver en premier lieu. Faites-le bien la première fois et vous n'aurez pas à le refaire plus tard.
Ce n'est pas utile. * "Q: Comment est-ce que je traite un bras cassé A: Ne vous cassez pas le bras." * Euh, d'accord, mais * j'ai un bras cassé * et c'est pourquoi je suis ici. –
Fondamentalement, si vous avez pas de contraintes de clé étrangère, vous pouvez le faire:
SELECT * FROM CHILD C WHERE C.PARENT_ID NOT IN (SELECT ID FROM PARENT);
-1; Premièrement, la situation décrite par le PO n'est pas une situation dans laquelle * "vous n'avez pas de contraintes de clé étrangère" *, et deuxièmement, cela ignore la condition "sur base de données entière" dans la question. –
Je pense qu'il est préférable de trouver et de gérer les « maux de tête » avant de mettre les mauvaises données dans la base de données. En désactivant les clés étrangères pour rendre les choses plus faciles, vous empirez les choses et vous annulez l'objectif d'avoir une clé étrangère pour commencer. Pré-traiter les données à la place.Ne mettez jamais sciemment de mauvaises données dans une base de données. – HLGEM
Vous pouvez utiliser http://stackoverflow.com/a/5977191/950503 pour vérifier toutes les violations de clé d'exportation. – windm