MySQL Fremdschlüssel Fehler 1005 errno 150
https://stackoverflow.com/questions/4063141
-
27-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Ich mache eine kleine Datenbank mit MySQL Workbench. Ich habe eine Haupttabelle, genannt "Immobili", die einen Primärschlüssel von vier Säulen aufgebaut hat. (Comune, Via, Civico, Immobile)
Nun, ich auch drei weitere Tische haben, Wich den gleichen Primärschlüssel haben (Comune, Via, Civico, Immobile), aber diese Felder auch auf die Tabelle Immobili verwiesen wird.
Erste Frage: Kann ich einen Primärschlüssel machen, der auch ein Fremdschlüssel ist
?Zweite Frage: Wenn ich versuche, um die Änderungen zu exportieren heißt es: Ausführen von SQL-Skript in Server
# 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
Anzeigen der Motor Status:
Fehler in Fremdschlüssel der Tabelle dbimmobili / valutazionimercato:
Es kann keinen Index in der referenzierten Tabelle finden, wo die referenzierten Spalten als die ersten Spalten angezeigt werden, oder Spalten typse in der Tabelle und die referenzierte Tabelle für Constraint nicht übereinstimmen. Beachten Sie, dass der interne Speichertyp ENUM und SET geändert in Tabellen, die mit> = InnoDB-4.1.12, und solche Spalten in der alten Tabellen können nicht durch solche Spalten referenziert werden in neuen Tabellen.
Wo ich falsch mache?
Lösung
Wenn Sie einen Fremdschlüssel erstellen, erfordert MySQL einen brauchbaren Index sowohl auf die verweisende Tabelle und auch auf der referenzierten Tabelle. Der Index für die verweisende Tabelle wird automatisch erstellt, wenn man nicht existiert, aber das eine auf die Bedürfnisse referenzierten Tabelle manuell ( Quelle ). Sie scheint zu fehlen.
Testfall:
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)
Aber wenn wir einen Index für some_other_id hinzufügen:
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)
Dies ist oft nicht ein Problem in den meisten Fällen, da die referenzierten Feld oft der Primärschlüssel der referenzierten Tabelle ist, und der Primärschlüssel automatisch indiziert.
Andere Tipps
Überprüfen Sie, dass die Fremdschlüssel haben genau die gleiche Art wie das Feld, das Sie in dieser Tabelle haben. Beispielsweise sollten beide Integer (10) oder Varchar (8), auch die Anzahl der Zeichen.
Ich weiß, dies ist eine alte Post, aber es steht hoch in Google, so dass ich das Hinzufügen, was ich für mein Problem gelöst. Wenn Sie eine Mischung aus Tabellentypen (z MyISAM und InnoDB) haben, werden Sie auch diesen Fehler. In diesem Fall ist InnoDB der Standard-Tabellentyp, sondern eine Tabelle Fulltextsuchung benötigt, so dass es zu MyISAM migriert wurde. In dieser Situation können Sie nicht einen Fremdschlüssel in der Tabelle InnoDB erstellen, dass Verweise der MyISAM-Tabelle.
Wenn Sie Ihren Schlüssel ein CHAR / VARCHAR oder etwas dieser Art ist, ein weiteres mögliches Problem ist, andere Sortierung. Überprüfen Sie, ob die charset ist die gleiche.
Ich hatte diesen Fehler und fand den Grund für den Fehler in meinem Fall. Ich bin immer noch auf diese alte Post zu beantworten, weil es ziemlich hoch auf Google Reihen.
Die Variablen sowohl der Spalte I Link wollte ganzen Zahlen waren aber einer der ints hatte ‚unsigned‘ aktiviert auf. Einfach un-Überprüfung, dass mein Fehler behoben.
Ich war einen gleichen Fehler. Ich fand die Lösung heraus, dass ich den Primärschlüssel in der Haupttabelle als BIGINT UNSIGNED geschaffen hatte und es als Fremdschlüssel in der zweiten Tabelle als nur BIGINT erklärt.
Wenn ich meinen Fremdschlüssel als BIGINT UNSIGED in der zweiten Tabelle erklärt, alles funktionierte gut, auch keine Indizes brauchte erstellt werden.
So ist es eine Datentypkonflikt zwischen dem Primärschlüssel und Fremdschlüssel war:)
ich hatte genau das gleiche Problem, aber die Lösung für mein Problem war ganz anders. Ich hatte, woanders in der Datenbank, einen Fremdschlüssel mit dem gleichen Namen. Das verursacht die Fehler 1005.
Umbenennen meine Fremdschlüssel, um etwas mehr spezifisch für diese Situation das Problem gelöst.
- Stellen Sie sicher, dass beide Tabellen den gleichen Motortyp verwenden.
- Stellen Sie sicher, dass die Felder, die Sie Indizierung sind, haben die gleiche Art und Länge.
In meinem Fall der Fehler aufgrund des referencing Tisches war, ist MyISAM wo als referring Tisch war InnoDB.
Converted Tabelle Motor aus MyISAM to InnoDB löst das Problem für mich.
ALTER TABLE table_name ENGINE=InnoDB;
Ich habe nicht den Ruf noch abstimmen Steves Vorschlag, aber es mein Problem gelöst.
In meinem Fall erhielt ich diesen Fehler, da die zwei Tabelle, in verschiedenen Datenbank-Engines erstellt wurden - war InnoDB und die andere MyISAM.
Sie können den Datenbanktyp ändern mit: ALTER TABLE t ENGINE = MYISAM;
http: //dev.mysql. com / doc / refman / 5.1 / de / storage-engine-setting.html
richtet das Augenmerk auf charset und COLLATE Parameter, wenn Sie eine Tabelle erstellen. Im Hinblick auf die FOREIGN KEY Probleme etwas wie folgt aus:
CREATE TABLE yourTableName (
....
....
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
In meinem Fall kann nicht ich die Tabelle mit Fremdschlüsselreferenzen erstellen. Zuerst bekam ich den Fehlercode 1005, der so ziemlich nichts sagt. Dann i hinzugefügt COLLATE und schließlich die Fehlermeldung über CHARSET beschweren.
Error Code: 1253. COLLATION 'utf8_unicode_ci' is not valid for CHARACTER SET 'latin1'
Danach Korrektur mein Problem gelöst wurde.
Es ist nicht Ihr spezieller Fall, aber es ist erwähnenswert, für alle andere, dass dieser Fehler kann auftreten, wenn Sie versuchen, einige Felder in einer Tabelle zu verweisen, die nicht der ganze Primärschlüssel dieser Tabelle sind. Offensichtlich ist dies nicht erlaubt.
Wenn jemand diesen Fehler mit scheinbar gut gebildet FK / PK Beziehungen hat und verwendet, um Sie das visuelle Werkzeug, versuchen Sie die säumige fk Spalten zu löschen und neu schöpf sie im Werkzeug. Ich war ständig immer diese Fehlermeldung, bis ich die Verbindungen neu entwarf, die die Fragen geklärt.
Wenn ein dort zwei Spalten für Primärschlüssel sind machen sie einen zusammengesetzten Primärschlüssel daher müssen Sie die in der Tabelle stellen Sie sicher, dass es auf die verwiesen wird, sind auch zwei Spalten der gleichen Datentyp.
Für mich, ich habe versucht ein reguläres indizierte Feld in einer untergeordneten Tabelle übereinstimmen, auf einen Primärschlüssel in der übergeordneten Tabelle und standardmäßig einige MySQL-Frontend GUIs wie Sequel Pro Satz der Primärschlüssel als nicht signiert, so dass Sie um sicherzustellen, dass auch nicht signiert ist das Kind Tabellenfeld (es sei denn, diese Felder negativ ints enthalten könnten, dann stellen sie sicher, sie sind beide unterzeichnet).
MySQL ist notorisch schlecht gelaunt, vor allem im Hinblick auf Fremdschlüssel und Trigger. Ich bin jetzt im Prozess der feinen tunning eine solche Datenbank, und lief in dieses Problem. Es ist nicht selbstverständlich oder intuitiv, so geht es hier:
Neben der Prüfung, ob die beiden Spalten, die Sie verweisen möchten, in der Beziehung den gleichen Datentyp haben, müssen Sie auch sicher, dass die Säule auf dem Tisch machen Sie verweisen ist ein Index. Wenn Sie die MySQL Workbench verwenden, wählen Sie die Registerkarte „Indizes“ rechts neben „Spalten“ und stellen Sie sicher, dass die Spalte durch den Fremdschlüssel referenziert ein Index ist. Wenn nicht, erstellen, nennen Sie es etwas Sinnvolles, und geben Sie ihm den Typ „INDEX“.
Eine gute Praxis ist es, die Tabellen in Beziehungen beteiligt aufzuräumen um sicherzustellen, dass frühere Versuche hat noch keinen Indizes erstellen Sie wollen oder müssen nicht.
Ich hoffe, es half, einige MySQL Fehler zu verfolgen sind aufreizend.
Erste Frage: Kann ich einen Primärschlüssel machen, der auch ein Fremdschlüssel ist
Ja. In der Tat für MySQL Workbench in der Gewohnheit, die ich habe für Fremdschlüssel Primärschlüssel nur bekommen. Wirklich verkürzt sich auf den zufälligen Fehlern empfangen, wie die err. 150 in der Frage angegeben
# ERROR: Fehler 1005: kann nicht erstellt werden Tabelle 'dbimmobili.condoni' (errno: 150)
Dies gilt mit Indizes, etwas haben, oder genauer gesagt, wie MySQL Workbench interpretiert und arbeitet mit ihnen. Es wird wirklich verwirrt, wenn Sie viel im Modell (zum Beispiel Fremdschlüssel, Indizes, col Aufträge) alle in dem gleichen Forward-Engineering Betrieb zu ändern, vor allem, wenn es bereits eine Datenbank auf dem anderen Ende . Zum Beispiel glaube ich nicht indiziert automatisch erstellt, in dem automatisch gelöscht, nachdem einen Fremdschlüssel zu löschen.
Hier ist, was ich habe den Fehler Ihren Empfang zu beheben. Beachten Sie, es scheint umständlich, aber im Vergleich zu der Menge an Zeit, die ich andere Methoden ausgegeben verwenden, ist es nicht.
1. Machen Sie alle Fremdschlüssel Primärschlüssel in der Lookup-Tabelle (die 1 in den 1 bis viele).
In meinem Fall beteiligt Ändern ID als pk Benutzernamen in tbl_users, zu Benutzernamen und Unternehmen in tbl_companies und zu Benutzernamen und Unternehmen und Ansprechpartner in tbl_company_contacts. Es ist eine App für mehrere Benutzer mehr Unternehmen Kontakte geben, so dass überlappende und Hidding anderer Nutzer Kontakte.
2. Löschen Sie alle Diagramm, das Beziehungen und alle Tabellenindex, die nicht Primärschlüssel sind.
Dies behebt die meisten der Index Probleme, die von einem Buggy MySQL Workbench wirklich verursacht werden.
3. Wenn Ihr diese von Anfang bis Ende zu tun, fallen das Schema auf dem Server, so ist MySQL Workbench nicht über die bestehenden indexs verwirren lassen und das Fehlen von dort in das Modell aus (Ausgabe wird bby Index und Fremdschlüsselbeziehung verursacht, nicht Index allein).
Das reduziert viele der Entscheidungen, die die DB, Server und MySQL Workbench hat viel zu machen. Diese Entscheidungen darüber, wie Ingenieur etwas zu übermitteln sind kompliziert und intelligent, aber unvollkommen.
4. Nun halte ich diese wieder auf Platz eins (in der Regel nach ohne einen gestuften Prozess zu viel zu schnell Gestaltung). Ich habe immer noch alle Tabellen, aber sie sind in diesem Stadium sauber. Jetzt einfach:
Als erstes vorwärts Ingenieur nur sicherstellen, dass die Tabellen (ohne Beziehungen) wie erwartet.
Mit der unten stehenden Beziehung Kette nach unten durch die Primärschlüssel, beginnend an dem obersten Tisch (ich bin meinen Fall tbl_users zu tbl_companies). Nach jeder Beziehung, Ingenieur immer nach vorne, um sicherzustellen, es läuft , dann das Modell speichern und zu schließen, dann Reverse das Modell Ingenieur um sicherzustellen, dass es zu machen nimmt . So können Sie schnell auf die Probleme isolieren, wie sie in meinem Fall entstehen, Index von alten verwendet links über Fremdschlüssel gelöscht (passiert 2-3 mal).
Und Tadda, zurück, wo Sie benötigt werden.
