MySQL chiave esterna Errore 1005 ERRNO 150

Question

che sto facendo un piccolo database con MySQL Workbench. Ho una tabella principale, chiamata "Immobili", che ha una chiave primaria composta da quattro colonne:. (Comune, Via, Civico, immobile)

Ora, ho anche altri tre tavoli, wich hanno la stessa chiave primaria (Comune, Via, Civico, immobile), ma questi campi sono anche fatto riferimento alla tabella di Immobili.

Prima domanda: Posso fare una chiave primaria che è anche una chiave esterna

?

Seconda Domanda: Quando si tenta di esportare i cambiamenti che dice:     L'esecuzione di script SQL 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

mostranti la condizione di motore:

  

Errore nel vincolo di chiave esterna della tabella dbimmobili / valutazionimercato:

     

Non riesci a trovare un indice nella tabella di riferimento in cui le colonne di riferimento appaiono come le prime colonne,       o le colonne typse nella tabella e la tabella di riferimento non corrispondono per costrizione. Si noti che il tipo di archiviazione interna di ENUM e SET cambiato nelle tabelle create con> =       InnoDB-4.1.12, e tali colonne in vecchie tabelle non possono essere referenziate da tali colonne       in nuove tabelle.

Dove sto facendo male?

Answer 1

Quando si crea un vincolo di chiave esterna, MySQL richiede un indice utilizzabile sia sul tavolo riferimento e anche sulla tabella di riferimento. L'indice nella tabella di corrispondenza viene generata automaticamente se uno non esiste, ma quello sulle esigenze tabella con i riferimenti da creare manualmente ( Fonte ). Distinti sembra mancare.

Test case:

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)

Ma se si aggiunge un indice su 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)

Questo non è spesso un problema nella maggior parte delle situazioni, poiché il campo di riferimento è spesso la chiave primaria della tabella di riferimento, e la chiave primaria viene indicizzato automaticamente.

Answer 2

Doppio controllo che le chiavi esterne hanno esattamente lo stesso tipo come il campo che hai in questa tabella. Ad esempio, entrambi di tipo intero (10), o Varchar (8), anche il numero di caratteri.

Answer 3

mi rendo conto che è un vecchio post, ma è ai primi posti in Google, quindi sto aggiungendo quello che ho capito per il mio problema. Se si dispone di un mix di tipi di tabella (ad esempio MyISAM e InnoDB), si ottiene questo errore pure. In questo caso, InnoDB è il tipo di tabella di default, ma aveva bisogno di un tavolo di ricerca full-text così è stato migrato a MyISAM. In questa situazione, non è possibile creare una chiave esterna nella tabella InnoDB che fa riferimento alla tabella MyISAM.

Answer 4

Se la chiave è un CHAR / VARCHAR o qualcosa di quel tipo, un altro possibile problema è diverso collazione. Controllare se il set di caratteri è lo stesso.

Answer 5

ho avuto questo errore e ho trovato la ragione per l'errore nel mio caso. Sto ancora rispondendo a questo vecchio post, perché si colloca piuttosto alto su Google.

Le variabili sia della colonna che volevo collegamento erano interi, ma uno degli interi avuto 'unsigned' controllati. Semplicemente deselezionando che risolto il mio errore.

Answer 6

mi è stato sempre uno stesso errore. Ho scoperto la soluzione che avevo creato la chiave primaria della tabella principale, come BIGINT UNSIGNED ed è stato dichiarato come una chiave esterna nella seconda tabella come solo BIGINT.

Quando ho dichiarato la mia chiave esterna come BIGINT UNSIGED nella seconda tabella, tutto ha funzionato bene, anche se non aveva bisogno di indici da creare.

Quindi è stata una mancata corrispondenza tipo di dati tra la chiave primaria e della chiave esterna:)

Answer 7

Ho avuto lo stesso problema, ma la soluzione al mio problema era completamente diverso. Ho avuto, da qualche altra parte nel database, una chiave esterna con lo stesso nome. Che ha causato l'errore 1005.

Rinominare la mia chiave esterna per qualcosa di più specifico a tale situazione ha risolto il problema.

Answer 8

1. Assicurarsi che entrambe le tabelle utilizzano lo stesso tipo di motore.
2. Assicurarsi che i campi si sono indicizzazione hanno lo stesso tipo e lunghezza.

Answer 9

Nel mio caso l'errore è dovuto al tavolo referencing è MyISAM dove come tavolo referring era InnoDB.

motore tavolo Converted dal MyISAM to InnoDB risolve il problema per me.

ALTER TABLE table_name ENGINE=InnoDB;

Answer 10

Non ho la reputazione ancora il suggerimento voto di Steve, ma risolto il mio problema.

Nel mio caso, ho ricevuto questo errore perché i due tavolo dove creata usando diversi motori di database - uno era InnoDB e MyISAM l'altro.

È possibile modificare il tipo di database utilizzando: ALTER TABLE t ENGINE = MyISAM;

http: //dev.mysql. com / doc / refman / 5.1 / it / storage-engine-setting.html

Answer 11

Dare attenzione alla CHARSET e COLLATE parametri quando si crea una tabella. In termini di FOREIGN KEY problemi di qualcosa di simile:

CREATE TABLE yourTableName (
....
....
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Nel mio caso non ho potuto creare la tabella con i riferimenti chiave esterna. In primo luogo ho ottenuto il codice di errore 1005 che dice praticamente nulla. Poi ho aggiunto COLLATE e, infine, il messaggio di errore lamentano CHARSET.

Error Code: 1253. COLLATION 'utf8_unicode_ci' is not valid for CHARACTER SET 'latin1'

Dopo che la correzione il mio problema è stato risolto.

Answer 12

Non è il tuo caso specifico, ma vale la pena notare per chiunque altro che questo errore può verificarsi se si tenta di fare riferimento alcuni campi di una tabella che non sono tutta la chiave primaria della tabella. Ovviamente questo non è consentito.

Answer 13

Se qualcuno ha questo errore con apparentemente ben formate relazioni FK / PK e si è utilizzato lo strumento visivo, provare a cancellare le colonne offendere FK e ri-aggiungendo nello strumento. Mi è stato continuamente ottenendo questo errore fino a quando ho ridisegnato i collegamenti che ha liquidato i problemi.

Answer 14

Quando un ci sono 2 colonne per le chiavi primarie che costituiscono una chiave primaria composta quindi è necessario assicurarsi che nella tabella a cui fa riferimento ci sono anche 2 colonne dello stesso tipo di dati.

Answer 15

Per quanto mi riguarda, stavo cercando di abbinare un campo indicizzato regolare in una tabella figlio, a una chiave primaria nella tabella padre, e per impostazione predefinita alcune interfacce grafiche MySQL frontend come Sequel Pro impostare la chiave primaria come senza segno, in modo da avere per assicurarsi che il campo tabella figlio non è firmato troppo (a meno che questi campi possono contenere interi negativi, quindi non sono entrambi firmati).

Answer 16

MySQL è notoriamente irritabile, soprattutto per quanto riguarda le chiavi esterne e trigger. Io sono in questo momento in fase di multa tunning una simile banca dati, ed ha funzionato in questo problema. Non è evidente o intuitivo, così qui va:

Oltre a verificare se le due colonne che si desidera di riferimento nel rapporto hanno lo stesso tipo di dati, è necessario inoltre assicurarsi che la colonna nella tabella si fa riferimento è un indice. Se si utilizza il MySQL Workbench, selezionare la scheda "Indici" accanto a "Colonne" e assicurarsi che la colonna a cui fa riferimento la chiave esterna è un indice. In caso contrario, crearne uno, il nome è qualcosa di significativo, e dargli il "INDEX" tipo.

Una pratica buona è quello di ripulire le tabelle coinvolte nei rapporti per assicurarsi che i precedenti tentativi non ha creato gli indici che non si desidera o necessità.

Spero che aiutato, alcuni errori di MySQL sono folli per tenere traccia.

Answer 17

  

Prima domanda:? Posso fare una chiave primaria che è anche una chiave esterna

Sì. Infatti per MySQL Workbench ho ottenuto l'abitudine di utilizzare soltanto chiavi primarie per chiavi esterne. taglia davvero giù sugli errori casuali ricevuti, come l'err:. 150 ha dichiarato nella domanda

  

# ERRORE: Errore 1005: Impossibile creare la tabella 'dbimmobili.condoni' (errno: 150)

Questo ha qualcosa a che con gli indici, o più specificamente come MySQL interpreta Workbench e lavora con loro. E 'davvero si confonde se si cambia molto nel modello (ad esempio, le chiavi esterne, indici, ordini col) tutti nella stessa operazione di ingegneria in avanti, soprattutto se v'è già un database all'altro capo . Per esempio, non credo che gli indici creati automaticamente dove eliminati automaticamente dopo l'eliminazione di una chiave esterna.

Ecco cosa ho fatto per correggere l'errore vostra ricezione. Nota, sembra ingombrante ma rispetto alla quantità di tempo che ho trascorso con altri metodi, non lo è.

1. Effettuare tutte le chiavi esterne chiavi primarie nella tabella di ricerca (l'1 in 1 a molti).

Nel mio caso questo id cambiare coinvolti come il pk al nome utente nella tbl_users, a nome utente e la società in tbl_companies, ea nome utente e la società e il contatto in tbl_company_contacts. E 'un app per più utenti di accedere più contatti aziendali, consentendo la sovrapposizione e Hidding di contatti di altri utenti.

2. Eliminare tutti i rapporti di diagrammi e tutto indice di tabella che non sono chiavi primarie.

Questo risolve la maggior parte dei problemi di indice che sono in realtà causati da un banco di lavoro MySQL buggy.

3. Se il vostro fare questo dall'inizio alla fine, eliminare lo schema sul server in modo da MySQL Workbench non venga confuso circa l'indexs esistenti e ci manca fuori nel modello (problema è causato BBY indice e relazione di chiave esterna, non indicizzare solo).

Questo riduce molte delle decisioni che il DB, server e MySQL Workbench devono fare un grande affare. Queste decisioni su come inoltrare ingegnere qualcosa sono complicate e intelligente, ma imperfetta.

4. Ora, ritengo questo ritorno a una piazza (in genere dopo la progettazione di troppo in fretta, senza un processo a gradini). Ho ancora tutti i tavoli, ma sono pulite in questa fase. Ora basta:

In primo luogo, ingegnere in avanti solo per assicurarsi che le tabelle (senza relazioni) funzionano come previsto.

Seguire la catena di relazioni verso il basso attraverso le chiavi primarie, a partire dalla cima più tavolo (io sono mio caso tbl_users a tbl_companies). Dopo ogni relazione, sempre in avanti ingegnere per assicurarsi che run , quindi salvare il modello e vicino, quindi il reverse engineering del modello per assicurarsi che si . Questo consente di isolare rapidamente i problemi che si presentano, nel mio caso lasciati indice utilizzato dal vecchio cancellati chiavi esterne (è successo 2-3 volte).

E Tadda, dove avete bisogno di essere.