MySQL Foreign Key Error 1005 errno 150
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 de quatre colonnes: (Comune, Via, Civico, Immobile).
maintenant, j'ai aussi trois autres tables, qui ont la même clé primaire (Comune, Via, Civico, Immobile), mais ces champs sont également référencés à la table Immobili.
première question: Puis-je faire une clé primaire qui est aussi une clé étrangère?
deuxième Question: quand j'essaie de exportez les changements qu'il dit: Exécution du script SQL 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:
impossible de trouver un index dans le tableau référencé où les colonnes référencées apparaissent comme les premières colonnes, ou les colonnes tapent dans le tableau et le tableau référencé ne correspondent pas à la contrainte. Notez que le type de stockage interne D'ENUM et SET a changé en les tables créées avec >= InnoDB-4.1.12, et de telles colonnes dans les anciennes tables ne peuvent pas être référencées par de telles colonnes dans de nouvelles tables.
où je me trompe?
17 réponses
lors de la création d'une contrainte de clé étrangère, MySQL requiert un index Utilisable à la fois sur la table de référencement et sur la table référencée. L'index sur la table de référencement est créé automatiquement si l'un n'existe pas, mais celui sur la table référencée doit être créé manuellement ( Source). Le vôtre semble avoir disparu.
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 nous ajoutons 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)
Ce n'est souvent pas un problème dans la plupart des les situations, depuis le champ référencé est souvent la clé primaire de la table référencée, et la clé primaire est automatiquement indexé.
vérifiez 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 devraient être entier(10), ou Varchar (8), même le nombre de caractères.
je me rends compte que c'est un vieux post, mais il se classe haut dans Google, donc j'Ajoute ce que j'ai trouvé pour mon problème. Si vous avez un mélange de types de table (par exemple MyISAM et InnoDB), vous obtiendrez cette erreur aussi. Dans ce cas, InnoDB est le type de table par défaut, mais une table a eu besoin d'une recherche fulltext donc elle a été migrée vers MyISAM. Dans cette situation, vous ne pouvez pas créer une clé étrangère dans la table InnoDB qui renvoie à la table MyISAM.
si votre clé est une CHAR / VARCHAR ou quelque chose de ce type, un autre problème possible est la collation différente. Vérifier si le jeu de caractères 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 post parce qu'il se classe assez haut sur Google.
les variables des deux colonnes que je voulais relier étaient des entiers mais un des ints avait coché "non signé". Décochant simplement que corrigé mon erreur.
je recevais une même erreur. J'ai découvert la solution que j'avais créé la clé primaire dans la table principale COMME BIGINT non signé et la déclarant comme une clé étrangère dans la deuxième table comme seulement BIGINT.
quand J'ai déclaré ma clé étrangère comme BIGINT Non gravée dans la deuxième table, tout a bien fonctionné, même pas besoin d'index pour être créé.
Donc, c'était un type de données d'incompatibilité entre la clé primaire et la clé étrangère :)
j'avais exactement le même problème, mais la solution à mon problème était complètement différente. J'avais, ailleurs dans la base de données, une clé étrangère avec le même nom. Cela a causé l'erreur 1005.
le fait de renommer ma clé étrangère pour quelque chose de plus spécifique à cette situation a résolu le problème.
- assurez-vous que les deux tableaux utilisent le même type de moteur.
- assurez-vous que les champs que vous indexez ont le même type et la même longueur.
Dans mon cas, l'erreur était due à l' referencing table MyISAM où referring table InnoDB.
Converted tableau de moteur de MyISAM to InnoDB résout le problème pour moi.
ALTER TABLE table_name ENGINE=InnoDB;
Je n'ai pas encore la réputation de voter la suggestion de Steve, mais ça a résolu mon problème.
dans mon cas, j'ai reçu cette erreur parce que les deux tables ont été créées en utilisant des moteurs de base de données différents--L'une était Innodb et l'autre MyISAM.
vous pouvez changer le type de base de données en utilisant : ALTER TABLE t ENGINE = MYISAM;
@voir http://dev.mysql.com/doc/refman/5.1/en/storage-engine-setting.html
ce n'est pas votre cas spécifique, mais il est intéressant de noter pour quelqu'un d'autre que cette erreur peut se produire si vous essayez de faire référence à certains champs dans une table qui ne sont pas la clé primaire entière de cette table. Évidemment, cela n'est pas autorisé.
si quelqu'un a cette erreur avec des relations FK/PK apparemment bien formées et que vous avez utilisé l'outil visuel, essayez de supprimer les colonnes FK offensantes et de les ajouter de nouveau dans l'outil. J'ai continuellement eu cette erreur jusqu'à ce que je redrew les connexions qui ont éclairci les problèmes.
quand a il y a 2 colonnes pour les clés primaires, elles constituent une clé primaire composite, donc vous devez vous assurer que dans le tableau qui est référencé il y a aussi 2 colonnes du même type de données.
pour moi, j'essayais de faire correspondre un champ indexé régulier dans une table enfant, à une clé primaire dans la table parent, et par défaut quelques interfaces graphiques MySQL comme Sequel Pro ont défini la clé primaire comme non signée, donc vous devez vous assurer que le champ de la table enfant n'est pas signé aussi (à moins que ces champs puissent contenir des entrées négatives, alors assurez-vous qu'ils sont tous les deux signés).
MySQL est notoirement grincheux, surtout en ce qui concerne les clés étrangères et les déclencheurs. Je suis en train de mettre au point une telle base de données, et j'ai rencontré ce problème. Il n'est ni évident ni intuitif, alors voici:
en plus de vérifier si les deux colonnes que vous voulez 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 référencez est un index. Si vous utilisez L'établi MySQL, sélectionnez l'onglet "Indices" juste à côté "Colonnes" et assurez-vous que la colonne référencée par la clé étrangère est un indice. Si ce n'est pas le cas, créez-en un, nommez quelque chose de significatif, et donnez-lui le type "INDEX".
une bonne pratique est de nettoyer les tables impliquées dans les relations pour s'assurer que les tentatives précédentes n'ont pas créé des index que vous ne voulez pas ou dont vous avez besoin.
j'espère que cela a aidé, certaines erreurs MySQL sont fâcheuses à suivre.
faites attention à CHARSET et COLLATE paramètres lorsque vous créez une table. en termes de clé étrangère problèmes de quelque chose comme ça:
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 de clé étrangère. J'ai d'abord eu le code D'erreur 1005 qui ne dit presque rien. Puis J'ai ajouté COLLATE et enfin le message d'erreur se plaignant de CHARSET.
Error Code: 1253. COLLATION 'utf8_unicode_ci' is not valid for CHARACTER SET 'latin1'
après cette correction mon numéro a été résolu.
première question: Puis-je faire une clé primaire qui est aussi une clé étrangère?
Oui. En fait, pour MySQL workbench, j'ai pris l'habitude de n'utiliser que les clés primaires pour les clés étrangères. Vraiment réduit les erreurs aléatoires reçu, comme l'err:150 indiqué dans la question.
# ERREUR: Erreur 1005: ne Peut pas créer la table 'dbimmobili.condoni' (errno: 150)
Ce n'est d'avoir quelque chose à avec des index, ou plus précisément comment MySQL workbench interprète et travaille avec eux. Il est vraiment confus si vous changez beaucoup dans le modèle (par exemple des clés étrangères, des index, des commandes de col) tout dans la même opération d'ingénierie avancée, surtout s'il y a déjà une base de données à l'autre extrémité. Par exemple, Je ne pense pas que les index créés automatiquement où supprimé automatiquement après la suppression d'une clé étrangère.
Voici ce que j'ai fait pour résoudre l'erreur de votre réception. Note, cela semble encombrant, mais par rapport au temps que j'ai passé à utiliser d'autres méthodes, ce n'est pas le cas.
1. Faire toutes les clés étrangères clés primaires dans la table de recherche (le 1 dans le 1 à beaucoup).
dans mon cas, cela impliquait de changer l'id comme pk pour username dans tbl_users, pour username et company dans tbl_compagnies, et pour username et company et contact dans tbl_company_contacts. C'est une application pour plusieurs utilisateurs pour entrer plusieurs contacts d'entreprise, permettant le chevauchement et cacher des contacts d'autres utilisateurs.
2. Supprimer toutes les relations de diagramme et tous les index de table qui ne sont pas des clés primaires.
cela corrige la plupart des problèmes d'index qui sont vraiment causés par un établi MySQL buggy.
3. Si vous faites cela du début à la fin, déposez le schéma sur le serveur pour que mysql workbench ne soit pas confondu avec les index existants et n'y manque pas dans le modèle (problème est causé par l'index bby et la clé étrangère relation, pas d'index).
cela réduit beaucoup de décisions que la base de données, le serveur et Mysql workbench doivent faire beaucoup. Ces décisions sur la façon de concevoir quelque chose en avant sont compliquées et intelligentes, mais imparfaites.
4. Maintenant, je considère ce retour à la case départ (généralement après la conception de beaucoup trop rapidement sans un processus pas à pas). J'ai encore toutes les tables, mais elles sont propres à ce stade. Maintenant, vous juste:
tout d'abord, ingénieur avant juste pour s'assurer que les tables (sans relations) fonctionnent comme prévu.
suivez la chaîne de relations à travers les touches primaires, en commençant par la table la plus haute (je suis tbl_users to tbl_compagnies). Après chaque relation, toujours avant ingénieur pour s'assurer qu'il pistes, puis enregistrez le modèle et fermer, puis désosser le modèle pour s'assurer qu'il faut. Cela vous permet de rapidement isolez les problèmes au fur et à mesure qu'ils se présentent, dans mon cas, l'index utilisé par les vieilles clés étrangères effacées (2-3 fois).
et tadda, de retour là où tu devais être.