Erreur MySQL Foreign Key 1005 numéro 150
https://stackoverflow.com/questions/4063141
-
27-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Je fais une petite base de données avec MySQL Workbench. J'ai une table principale, appelée "Immobili", qui a une clé primaire composée par quatre colonnes:. (Comune, Via, Civico, Immobile)
Maintenant, j'ai aussi trois autres tables, Wich ont la même clé primaire (Comune, Via, Civico, Immobile), mais ces champs sont également mentionnés à la table Immobili.
Première question: Puis-je faire une clé primaire qui est aussi un étranger clé
?Deuxième question: Quand je tente d'exporter les changements qu'il dit: script SQL exécution dans le serveur
# ERROR: Error 1005: Can't create table 'dbimmobili.condoni' (errno: 150)
CREATE TABLE IF NOT EXISTS `dbimmobili`.`Condoni` (
`ComuneImmobile` VARCHAR(50) NOT NULL ,
`ViaImmobile` VARCHAR(50) NOT NULL ,
`CivicoImmobile` VARCHAR(5) NOT NULL ,
`InternoImmobile` VARCHAR(3) NOT NULL ,
`ProtocolloNumero` VARCHAR(15) NULL ,
`DataRichiestaSanatoria` DATE NULL ,
`DataSanatoria` DATE NULL ,
`SullePartiEsclusive` TINYINT(1) NULL ,
`SullePartiComuni` TINYINT(1) NULL ,
`OblazioneInEuro` DOUBLE NULL ,
`TecnicoOblazione` VARCHAR(45) NULL ,
`TelefonoTecnico` VARCHAR(15) NULL ,
INDEX `ComuneImmobile` (`ComuneImmobile` ASC) ,
INDEX `ViaImmobile` (`ViaImmobile` ASC) ,
INDEX `CivicoImmobile` (`CivicoImmobile` ASC) ,
INDEX `InternoImmobile` (`InternoImmobile` ASC) ,
PRIMARY KEY (`ComuneImmobile`, `ViaImmobile`, `CivicoImmobile`, `InternoImmobile`) ,
CONSTRAINT `ComuneImmobile`
FOREIGN KEY (`ComuneImmobile` )
REFERENCES `dbimmobili`.`Immobile` (`ComuneImmobile` )
ON DELETE CASCADE
ON UPDATE CASCADE,
CONSTRAINT `ViaImmobile`
FOREIGN KEY (`ViaImmobile` )
REFERENCES `dbimmobili`.`Immobile` (`ViaImmobile` )
ON DELETE CASCADE
ON UPDATE CASCADE,
CONSTRAINT `CivicoImmobile`
FOREIGN KEY (`CivicoImmobile` )
REFERENCES `dbimmobili`.`Immobile` (`CivicoImmobile` )
ON DELETE CASCADE
ON UPDATE CASCADE,
CONSTRAINT `InternoImmobile`
FOREIGN KEY (`InternoImmobile` )
REFERENCES `dbimmobili`.`Immobile` (`InternoImmobile` )
ON DELETE CASCADE
ON UPDATE CASCADE
) ENGINE = InnoDB
affichage de l'état du moteur:
Erreur dans la contrainte de clé étrangère de la table dbimmobili / valutazionimercato:
Vous ne trouvez pas un index dans la table référencée où les colonnes référencées apparaissent comme les premières colonnes, ou colonnes typse dans la table et la table référencée ne correspondent pas à la contrainte. Notez que le type de stockage interne de ENUM et SET changé dans les tableaux créés avec> = InnoDB-4.1.12, et ces colonnes dans les vieux tableaux ne peuvent pas être référencées par ces colonnes dans les nouvelles tables.
Si je fais mal?
La solution
Lors de la création d'une contrainte de clé étrangère, MySQL requiert un index utilisable tant sur la table de référencement et aussi sur la table référencée. L'indice sur la table de référencement est créé automatiquement si l'on n'existe, mais celui sur les besoins de la table référencée à créer manuellement ( Source). Vôtre semble manquer.
Cas de test:
CREATE TABLE tbl_a (
id int PRIMARY KEY,
some_other_id int,
value int
) ENGINE=INNODB;
Query OK, 0 rows affected (0.10 sec)
CREATE TABLE tbl_b (
id int PRIMARY KEY,
a_id int,
FOREIGN KEY (a_id) REFERENCES tbl_a (some_other_id)
) ENGINE=INNODB;
ERROR 1005 (HY000): Can't create table 'e.tbl_b' (errno: 150)
Mais si l'on ajoute un index sur some_other_id:
CREATE INDEX ix_some_id ON tbl_a (some_other_id);
Query OK, 0 rows affected (0.11 sec)
Records: 0 Duplicates: 0 Warnings: 0
CREATE TABLE tbl_b (
id int PRIMARY KEY,
a_id int,
FOREIGN KEY (a_id) REFERENCES tbl_a (some_other_id)
) ENGINE=INNODB;
Query OK, 0 rows affected (0.06 sec)
Ceci est souvent un problème dans la plupart des situations, puisque le champ référencé est souvent la clé primaire de la table référencée, et la clé primaire est indexé automatiquement.
Autres conseils
Vérifier que les clés étrangères ont exactement le même type que le champ que vous avez dans ce tableau. Par exemple, les deux doivent être des nombres entiers (10), ou Varchar (8), même le nombre de caractères.
Je sais que c'est un ancien poste, mais il occupe un rang élevé dans Google, donc je suis d'ajouter ce que je pensais pour mon problème. Si vous avez un mélange de types de table (par exemple MyISAM et InnoDB), vous obtiendrez cette erreur aussi bien. Dans ce cas, InnoDB est le type de table par défaut, mais une table nécessaire la recherche plein texte de sorte qu'il a été migré vers MyISAM. Dans cette situation, vous ne pouvez pas créer une clé étrangère dans la table InnoDB que les références de la table MyISAM.
Si votre clé est un CHAR / VARCHAR ou quelque chose de ce type, un autre problème possible est différent collation. Vérifiez si le charset est le même.
J'ai eu cette erreur et a trouvé la raison de l'erreur dans mon cas. Je réponds toujours à ce vieux poste car il se classe assez élevé sur Google.
Les variables des deux de la colonne que je voulais lien étaient entiers, mais l'un des ints avait « non signé » cochée sur. Il suffit décochant que fixe mon erreur.
Je recevais une même erreur. J'ai trouvé la solution que j'avais créé la clé primaire dans le tableau principal comme UNSIGNED BIGINT et a été déclaré comme une clé étrangère dans la seconde table que BIGINT.
Quand je déclarais ma clé étrangère BIGINT UNSIGED dans la deuxième table, tout fonctionnait bien, même n'a pas besoin d'index à créer.
Il était une incompatibilité de type de données entre la clé primaire et la clé étrangère:)
J'ai eu exactement le même problème, mais la solution à mon problème était tout à fait différent. J'ai eu, quelque part ailleurs dans la base de données, une clé étrangère avec le même nom. Qui a causé l'erreur 1005.
Changement de nom ma clé étrangère à quelque chose de plus spécifique à cette situation a résolu le problème.
- Assurez-vous que les deux tables utilisent le même type de moteur.
- Assurez-vous que les champs que vous indexez ont le même type et la longueur.
Dans mon cas, l'erreur est due à la table referencing est MyISAM où comme table referring était InnoDB.
moteur de table Converted de MyISAM to InnoDB résout le problème pour moi.
ALTER TABLE table_name ENGINE=InnoDB;
Je n'ai pas la réputation encore la suggestion de vote Steve, mais il a résolu mon problème.
Dans mon cas, je reçu cette erreur, car les deux table où créée en utilisant différents moteurs de base de données - l'un était InnoDB et l'autre MyISAM.
Vous pouvez modifier le type de base de données en utilisant: ALTER TABLE t MOTEUR = MyISAM;
http: //dev.mysql. com / doc / refman / 5.1 / fr / storage-engine-setting.html
Prêter attention à l' charset et COLLATE paramètres lorsque vous créez une table. En termes de problèmes quelque chose comme FOREIGN KEY :
CREATE TABLE yourTableName (
....
....
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
Dans mon cas, je ne pouvais pas créer la table avec des références FOREIGN KEY. Tout d'abord je suis le Code d'erreur 1005 qui dit à peu près rien. Ensuite, i ajouté COLLATE et enfin le message d'erreur se plaindre de charset.
Error Code: 1253. COLLATION 'utf8_unicode_ci' is not valid for CHARACTER SET 'latin1'
Après cette correction mon problème a été résolu.
Il est pas votre cas spécifique, mais il vaut la peine de noter de quelqu'un d'autre pour que cette erreur peut se produire si vous essayez de référencer certains champs dans une table qui ne sont pas toute la clé primaire de cette table. Il est évident que ce n'est pas autorisé.
Si quelqu'un a cette erreur avec les relations FK / PK apparemment bien formés et vous avez utilisé l'outil visuel, essayez de supprimer les colonnes fk incriminée et les re-ajouter dans l'outil. Je recevais sans cesse cette erreur jusqu'à ce que je redessine les connexions qui éclaircis les questions.
Lorsqu'un il y a 2 colonnes pour les clés primaires, ils constituent une clé primaire composite donc vous devez vous assurer que la table qui est référencée il y a aussi 2 colonnes du même type de données.
Pour moi, je tentais de faire correspondre un champ indexé régulièrement dans une table enfant, à une clé primaire dans la table parent, et par défaut certains frontend MySQL interfaces graphiques comme Sequel Pro Set la clé primaire non signé, de sorte que vous avez pour vous assurer que le champ de la table des enfants est trop non signé (à moins que ces champs peuvent contenir des ints négatifs, alors assurez-vous qu'ils sont tous deux signés).
MySQL est notoirement mauvaise humeur, en particulier en ce qui concerne les clés et les déclencheurs étrangers. Je suis en ce moment dans le processus de fin tunning une telle base de données, et a couru dans ce problème. Il n'est pas évident ou intuitive, ici il va:
En plus de vérifier si les deux colonnes que vous souhaitez référencer dans la relation ont le même type de données, vous devez également vous assurer que la colonne sur la table que vous faites référence est un indice. Si vous utilisez le Workbench MySQL, sélectionnez l'onglet « Index » juste à côté de « colonnes » et assurez-vous que la colonne référencée par la clé étrangère est un indice. Sinon, créez un, nommez quelque chose de significatif, et lui donner le type « INDEX ».
Une bonne pratique consiste à nettoyer les tables impliquées dans des relations pour faire des tentatives précédentes que ne créer des index que vous ne voulez pas ou besoin.
Je l'espère aidé, quelques erreurs de MySQL sont affolantes à suivre.
Première question: Puis-je faire une clé primaire qui est aussi un étranger clé
Oui. En fait pour établi MySQL J'ai pris l'habitude d'utiliser seulement les clés primaires pour les clés étrangères. coupe vraiment vers le bas sur les erreurs aléatoires reçues, comme le err. 150 indiqué dans la question
# ERREUR: Erreur 1005: Impossible de créer la table 'dbimmobili.condoni' (errno: 150)
a quelque chose à des indices, ou plus précisément comment interprète MySQL Workbench et travaille avec eux. Il devient vraiment confus si vous changez beaucoup dans le modèle (par exemple des clés étrangères, les indices, les commandes de col) dans la même opération d'ingénierie en avant, surtout s'il y a déjà une base de données à l'autre bout . Par exemple, je ne pense pas que les index créés automatiquement lorsque supprimés automatiquement après la suppression d'une clé étrangère.
Voici ce que je l'ai fait pour corriger l'erreur de votre réception. Remarque, il semble compliqué, mais par rapport à la quantité de temps passé à l'aide d'autres méthodes, ce n'est pas.
1. Faire toutes les clés primaires clés étrangères dans la table de consultation (le 1 dans le 1 à plusieurs).
Dans mon cas, cela impliquait id changer comme pk nom d'utilisateur dans tbl_users, pour nom d'utilisateur et de l'entreprise dans tbl_companies, et le nom d'utilisateur et de l'entreprise et des contacts en tbl_company_contacts. Il est une application pour plusieurs utilisateurs d'entrer plusieurs contacts de l'entreprise, ce qui permet de chevauchement et Hidding d'autres contacts des utilisateurs.
2. Supprimer toutes les relations de diagramme et tous les index de la table qui ne sont pas les clés primaires.
Elle corrige la plupart des problèmes d'index qui sont vraiment causés par une table de travail de MySQL buggy.
3. Si vous faites cela, du début à la fin, laissez tomber le schéma sur le serveur afin établi mysql ne pas confondre sur les indexs existants et défaut de sécurité dans le modèle (problème est dû à BBY index et relation clé étrangère, et non l'indice seul).
Cela réduit beaucoup des décisions que le plan de travail DB, serveur et Mysql doivent faire beaucoup. Ces décisions sur la façon de transmettre quelque chose ingénieur sont compliquées et intelligent, mais imparfait.
4. Maintenant, je considère que ce retour à un carré (généralement après la conception de beaucoup trop rapidement, sans le développement du processus). J'ai encore toutes les tables, mais elles sont propres à ce stade. Maintenant que vous venez de:
Tout d'abord, ingénieur en avant juste pour vous assurer que les tables (sans relations) travail comme prévu.
Suivez la chaîne de relation vers le bas à travers les clés primaires, en commençant par le plus haut sommet table (je suis mon cas tbl_users à tbl_companies). Après chaque relation, toujours ingénieur en avant pour vous assurer qu'il fonctionne , puis enregistrez le modèle et fermer, puis désosser le modèle pour vous assurer qu'il prend . Cela vous permet d'isoler rapidement les problèmes qui se présentent, dans mon cas gauche sur l'index utilisé par les anciens délétés clés étrangères (arrivé 2-3 fois).
Et Tadda, là où vous avez besoin d'être.
