Para usar una clave externa en MySQL o no?

He estado codificando con MySQL DBs desde hace un par de años y nunca he usado una clave externa. Ahora, entiendo que una clave externa es como una ID en una tabla que corresponde con una clave primaria de otra tabla. Tengo una tabla de usuario en mi sitio y probablemente alrededor de otras 10 tablas que se corresponden con la clave principal de mi tabla de usuario; sin embargo, no están configuradas como claves externas.Para usar una clave externa en MySQL o no?

¿Qué me estoy perdiendo al no tener estas otras 10 tablas con una clave externa? Quiero decir, hasta donde puedo decir, básicamente son una clave externa, excepto que no tienen ese valor guardado/asignado a ellos en la base de datos.

¿Hay alguna otra ventaja aquí de la que no estoy al tanto?

También me doy cuenta de que una clave principal no puede ser nula, pero puede ser una clave externa. Esto nunca será un problema en mi caso ya que se creó mi tabla de usuarios, y cuando se agrega un nuevo usuario a mi tabla de usuarios, agrego su entrada apropiada a las otras 10 tablas.

Fuente

2009-08-07 JasonDavis

Estoy viendo un montón de "usted puede hacerlo usted mismo en el código" en las respuestas aquí, y está muy equivocado. No puedo contar cuántas bases de datos he visto que se han convertido en un lío de datos no válidos en el transcurso de meses y años. Sin excepción, cada uno de ellos habría estado perfectamente limpio si la integridad referencial se hubiera aplicado correctamente en el esquema. Las claves externas no son opcionales, son un componente clave del buen diseño de la base de datos. –

Un FOREIGN KEY sirve para dos propósitos:

Asegura que las relaciones son siempre consistentes a costa de algunas comprobaciones sobrecarga
It (disputably) simplifica las actualizaciones en cascada y eliminaciones.

En la mayoría de los casos, esta funcionalidad se puede implementar de manera más eficiente utilizando otras herramientas.

Fuente

2009-08-07 18:26:21 Quassnoi

No estoy de acuerdo aquí. Entonces asume que siempre habrá una capa adicional sobre la base de datos que cumple los propósitos que ya tiene la base de datos. Veo que esto se convierte en un enfoque bastante moderno, pero todavía lo considero bastante malo. –

@ Jan: la capa normalmente utilizada para eso se denomina procedimientos almacenados, y no está "sobre" el 'DB'. La principal desventaja de las claves externas es su implementación fila por fila, que es un asesino de rendimiento si necesita hacer actualizaciones masivas de forma más o menos regular. – Quassnoi

¿Entonces creará para cada tabla algo así como antes de insertar el desencadenador para imponer la restricción? ¿Es realmente más eficiente? Solo preguntando, sin decir que no lo es. Realmente curioso Porque puede hacer algo así como una API de procedimientos almacenados que deberían usarse para insertar/actualizar datos, pero ¿es 100% seguro? ¿Qué pasa si alguien llama el inserto directamente? –

Lo que se está perdiendo es integridad referencial forzada (es decir, si su otra tabla tiene user_id 27, DEBE tener un ID 27 en la tabla de usuario) y la capacidad de tener actualizaciones y eliminaciones automáticas en cascada (es decir, eliminar usuario 27, las filas correspondientes en la otra tabla también se eliminan automáticamente, etc.).

En mi opinión, no vale la pena. Soy perfectamente capaz de tener la integridad referencial de mi dirección de código, y tratar con claves externas es una molestia de mantenimiento enorme.

Fuente

2009-08-07 18:25:03 chaos

Actualmente, cuando un usuario borra una cuenta, elimino mi código de las otras 10 o más tablas, ¿está diciendo que esto podría automatizarse? Tengo más curiosidad acerca de que menciones la actualización, ¿qué hará eso? – JasonDavis

@ chaos: estoy seguro de que tu código es siempre perfecto en la aplicación de la integridad referencial, pero ¿qué pasa con el código * de otras personas que accede a la misma base de datos? ¿O las consultas ad hoc se ejecutan en una herramienta de consulta? El objetivo del RI impuesto por la base de datos es que sea uniforme incluso si el cliente no lo es. –

Con las claves externas que

puede asegurarse de que la user_id válidas sólo se ponen a esos campos
cascadas uso de borrado fácil
no tienen que definir manualmente los índices de campos (innodb)

Fuente

2009-08-07 18:28:02 Zed

en algunas bases de datos (no estoy seguro sobre MySQL), un FOREIGN KEY indexa automáticamente, lo que acelera muy bien sus Uniones y consultas sobre las claves externas. Además, están los beneficios ya mencionados de eliminaciones en cascada, integridad referencial, etc.

Fuente

2009-08-07 18:28:40

Definir una clave externa en MySQL es básicamente un alias para configurar 1) un índice 2) una restricción (la fkey real), así que sí, obtienes un índice fuera de él. – chaos

Agregar claves externas siempre es una buena idea, al menos nunca he visto una razón convincente para no usarlas.

exige la integridad referencial (no se puede eliminar un padre si existe un niño, no puede insertar huérfanos, o un niño con un ID de padre inválido)
funciona como un índice
Con las claves externas, no importa cómo se acceda a los datos, ya sea a través de una aplicación, un proceso automático o alguien sin cafeína en la terminal, las reglas se aplican de manera uniforme.

Fuente

2009-08-19 12:03:58

escala difícil cuando utiliza claves externas – Pegasus

Para usar una clave externa en MySQL o no?

Respuesta

Cuestiones relacionadas