MySQL clave externa de error 1005 de error 150

https://stackoverflow.com/questions/4063141

27-09-2019
|

Pregunta

Estoy haciendo una pequeña base de datos con MySQL Workbench. Tengo una tabla principal, llamada "Immobili", que tiene una clave principal compuesta por cuatro columnas:. (Comune, Via, Civico, inmóvil)

Ahora, también tengo otras tres mesas, cosa que tienen la misma clave primaria (Comune, Via, Civico, inmóviles), pero estos campos también se refieren al punto Immobili mesa.

Primera pregunta: ¿Puedo hacer una clave principal que es también una clave externa

Segunda Pregunta: Cuando intento exportar los cambios que dice: La ejecución de secuencias de comandos SQL en el servidor

# 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

que muestra el estado del motor:

Error en la restricción de clave externa de la tabla dbimmobili / valutazionimercato:

No se puede encontrar un índice en la tabla referenciada donde las columnas referenciadas aparecen como las primeras columnas,       o columnas typse en la tabla y la tabla de referencia no coinciden para la restricción. Tenga en cuenta que el tipo de almacenamiento interna de ENUM y SET cambió en tablas creadas con> =       InnoDB-4.1.12, y dichas columnas de las tablas de edad no pueden ser referenciados por dichas columnas       en las nuevas tablas.

¿Dónde estoy haciendo mal?

Solución

Al crear una restricción de clave externa, MySQL requiere un índice utilizable tanto en la tabla de referencia y también en la tabla referenciada. El índice en la tabla de referencia se crea automáticamente si no existe uno, pero el de las necesidades de la tabla hace referencia a crearse manualmente ( Fuente ). El suyo parece que falta.

caso de prueba:

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)

Pero si añadimos un índice en 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)

Esto no es a menudo un problema en la mayoría de situaciones, ya que el campo se hace referencia es a menudo la clave primaria de la tabla de referencia, y la clave principal se indexa automáticamente.

Otros consejos

a comprobar que las claves externas tienen exactamente el mismo tipo que el campo que ha obtenido en esta tabla. Por ejemplo, ambos deben estar entero (10), o VARCHAR (8), incluso el número de caracteres.

Me di cuenta que es una entrada antigua, pero ocupa un lugar destacado en Google, así que estoy añadiendo lo que me di cuenta de mi problema. Si usted tiene una mezcla de tipos de tabla (por ejemplo, MyISAM y InnoDB), obtendrá este error también. En este caso, InnoDB es el tipo de tabla por defecto, pero necesita una tabla de búsqueda de texto completo por lo que se ha migrado a MyISAM. En esta situación, no se puede crear una clave externa en la tabla InnoDB que las referencias de la tabla MyISAM.

Si la clave es un CHAR / VARCHAR o algo de ese tipo, otro posible problema es diferente de colación. Compruebe si el conjunto de caracteres es el mismo.

tuve este error y encontré el motivo del error en mi caso. Todavía estoy respondiendo a esta entrada antigua, ya que ocupa bastante alto en Google.

Las variables tanto de la columna que quería enlace estaban enteros, pero uno de los enteros tenido 'sin firmar' comprueban en. Simplemente desactivando que fija mi error.

Me estaba poniendo un mismo error. Descubrí la solución que había creado la clave principal en la tabla principal como BIGINT sin firmar y declarar que estaba como una clave externa en la segunda tabla, ya que sólo BIGINT.

Cuando declaré mi clave externa como BIGINT UNSIGED en la segunda mesa, todo funcionaba bien, incluso no necesita ningún índice que se creará.

Así que fue una falta de coincidencia de tipo de datos entre la clave principal y la clave externa:)

Yo tenía el mismo problema, pero la solución a mi problema era totalmente diferente. Tenía, en otra parte de la base de datos, una clave externa con el mismo nombre. Que provocó el error 1005.

Cambiar el nombre de mi clave externa a algo más específico a esa situación resuelto el problema.

Asegúrese de que ambas tablas están utilizando el mismo tipo de motor.
Asegúrese de que los campos que son la indexación tienen el mismo tipo y longitud.

En mi caso, el error se debió a la mesa referencing es MyISAM donde como mesa referring era InnoDB.

Motor de mesa Converted de MyISAM to InnoDB resuelve el problema para mí.

ALTER TABLE table_name ENGINE=InnoDB;

No tengo la reputación todavía a la sugerencia voto de Steve, pero resolvió mi problema.

En mi caso, he recibido este error, porque los dos mesa donde ha creado usando diferentes motores de bases de datos - uno era de Innodb y el otro MyISAM.

Puede cambiar el tipo de base de datos utilizando: ALTER TABLE t = MOTOR MYISAM;

http: //dev.mysql. com / doc / RefMan / 5.1 / es / storage-engine-setting.html

prestar atención a CHARSET y COLLATE parámetros cuando se crea una tabla. En términos de Relaciones CLAVE problemas algo así:

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

En mi caso no pude crear la tabla de referencias clave extranjero. En primer lugar tengo el código de error 1005, que dice casi nada. Entonces i añadido COLLATE y, finalmente, el mensaje de error quejándose de CHARSET.

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

Después de que la corrección de mi problema fue solucionado.

No es su caso específico, pero no vale de nada para nadie más que se puede producir este error si intenta hacer referencia a algunos campos de una tabla que no son toda la clave primaria de esa tabla. Obviamente, esto no está permitido.

Si alguien tiene este error con las relaciones FK / PK aparentemente bien formados y que utiliza la herramienta visual, trate de eliminar las columnas ofensivo FK y re-adición de ellos en la herramienta. Me estaba continuamente este error hasta que redibujé las conexiones de los cuales aclaradas las cuestiones.

Cuando una hay 2 columnas para las claves principales que componen una clave principal compuesta por lo tanto usted tiene que asegurarse de que en la tabla que se está haciendo referencia también hay 2 columnas del mismo tipo de datos.

Para mí, yo estaba tratando de hacer coincidir un campo indexado regular en una tabla secundaria, a una clave principal en la tabla principal, y por defecto algunas interfaces gráficas de usuario MySQL frontend como secuela conjunto Pro la clave principal como sin firmar, por lo que tiene para asegurarse de que el campo de tabla secundaria no está firmado también (a menos que estos campos podrían contener enteros negativos, a continuación, asegúrese de que los dos están firmados).

MySQL es notoriamente mal humor, especialmente con respecto a las claves externas y los factores desencadenantes. Estoy ahora en el proceso de ajuste fino una tal base de datos, y se encontró con este problema. No es evidente por sí mismo o intuitivo, así que aquí va:

Además de comprobar si las dos columnas que desea hacer referencia en la relación tienen el mismo tipo de datos, también debe asegurarse de que la columna en la tabla que está haciendo referencia es un índice. Si está usando el MySQL Workbench, seleccione la pestaña "Índices" justo al lado de "Columnas" y asegúrese de que la columna referenciada por la clave externa es un índice. Si no es así, crear uno, nombrarlo algo significativo, y darle el "índice" de tipo.

Una buena práctica es limpiar las tablas involucradas en las relaciones de hacer intentos anteriores Seguro no crear índices que no desea o necesita.

Espero que ayudó, algunos errores de MySQL están enloqueciendo para realizar un seguimiento.

Primera pregunta: ¿Puedo hacer una clave principal que es también una clave externa

Sí. De hecho, para MySQL Workbench que he recibido en el hábito de utilizar únicamente las claves principales para las claves externas. Realmente reduce los errores aleatorios recibidos, como el err:. 150 señalado en la pregunta

# ERROR: Error 1005: No se puede crear la tabla 'dbimmobili.condoni' (Error: 150)

Esto tiene algo que ver con los índices, o más específicamente cómo MySQL interpreta banco de trabajo y trabaja con ellos. Realmente se confunde si cambia mucho en el modelo (por ejemplo, claves foráneas, índices, órdenes col) todos en la misma operación de ingeniería hacia adelante, especialmente si ya existe una base de datos en el otro extremo . Por ejemplo, no creo que los índices creados automáticamente cuando eliminan automáticamente después de eliminar una clave externa.

Esto es lo que hice para corregir el error a su recepción. Nota, parece complicado pero en comparación con la cantidad de tiempo que pasé con otros métodos, no lo es.

1. Haga todas las claves externas claves primarias en la tabla de búsqueda (el 1 en el 1 a muchos).

En mi caso esto implicaba Identificación cambiando a medida que el pico a nombre de usuario en tbl_users, a nombre de usuario y compañía en tbl_companies, ya nombre de usuario y la empresa y el contacto en tbl_company_contacts. Es una aplicación para múltiples usuarios introducir múltiples contactos de la empresa, lo que permite la superposición y HIDDING de otros usuarios contactos.

2. Eliminar todas las relaciones diagrama y todo índice de la tabla que no son claves primarias.

Esto fija la mayoría de los problemas de índice que realmente son causadas por un banco de trabajo de MySQL con errores.

3. Si su hacer esto de principio a fin, descartar el esquema en el servidor para banco de trabajo MySQL no se confunda acerca de los indices existentes y la falta de allí fuera en el modelo (problema está causado bby índice y relación de clave externa, no solo índice).

Esto reduce muchas de las decisiones que la base de datos, servidor y MySQL Workbench tiene que hacer una gran cantidad. Estas decisiones sobre cómo enviar el ingeniero de algo son complicadas e inteligente, pero imperfecta.

4. Ahora, considero que este regreso a un cuadrado (por lo general después de diseñar a demasiado rápidamente sin un proceso escalonado). Todavía tengo todas las tablas, pero están limpias en esta etapa. Ahora sólo:

En primer lugar, el ingeniero adelante sólo para asegurarse de que las tablas (sin relación) funcionan como se esperaba.

Siga la cadena de relaciones hacia abajo a través de las claves primarias, comenzando en la parte superior la mayoría de mesa (yo soy mi tbl_users casos para tbl_companies). Después de cada relación, siempre adelante ingeniería para asegurarse de que carreras , a continuación, guardar el modelo y cerrar, a continuación, realizar ingeniería inversa del modelo para asegurarse de que tiene . Esto le permite aislar rápidamente los problemas que puedan surgir, en mi caso la izquierda sobre el índice utilizado por edad suprimido las claves externas (ocurrieron 2-3 veces).

Y Tadda, de vuelta donde tenía que estar.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow