database - relacionar - llaves foraneas mysql workbench
¿Necesita absolutamente claves foráneas en una base de datos? (11)
Creo que suponer que los programadores siempre preservarán la integridad de los datos es una suposición arriesgada.
No hay ninguna razón por la que no crearía claves externas, y ser capaz de garantizar la integridad en lugar de solo esperar la integridad es una razón suficiente.
Me preguntaba cuán útiles son realmente las claves foráneas en una base de datos. Esencialmente, si los desarrolladores saben de qué claves dependen las diferentes tablas, pueden escribir las consultas como si hubiera una clave externa, ¿verdad?
Además, veo cómo las restricciones de clave foránea ayudan a prevenir todo tipo de errores con la integridad de los datos, pero, por ejemplo, los programadores hacen un buen trabajo para preservar la integridad de los datos, ¿qué tan necesarias son las claves foráneas realmente?
La gente ha ofrecido algunas buenas respuestas arriba. Sin embargo, un punto importante que no vi mencionado es que las claves foráneas hacen que los diagramas de relación de entidad (ERD) sean más fáciles de generar y mucho más significativos. Sin los FK, debe representar las relaciones de FK en su ERD manualmente (doloroso para usted) o no hacerlo (doloroso para los demás, y quizás incluso para usted mismo una vez que su memoria de las relaciones de FK implícitas comience a desvanecerse con el tiempo). Con los FK definidos explícitamente, la mayoría de las herramientas que generan ERD automáticamente a partir de las definiciones de objetos de la base de datos detectarán y representarán automáticamente las relaciones FK. Espero que esto ayude.
Las claves externas son invaluables para garantizar la integridad, e incluso si confía en que sus desarrolladores nunca cometan errores (!), El costo de tenerlos por lo general vale la pena.
Las claves externas también sirven como documentación, ya que puedes ver qué se relaciona con qué. Esta información también suele ser utilizada por herramientas, como para generar informes, crear conjuntos de datos a partir de definiciones de tablas, asignadores de objetos relacionales, etc. Incluso si no usa ninguno de estos hoy, tener FK hará que sea más fácil recorrer esa ruta. luego.
Las claves externas también le permiten definir reglas de cascada, que, por ejemplo, se pueden usar para eliminar registros asociados en tablas relacionadas cuando se elimina una fila en una tabla.
Solo si tiene cargas ridículamente altas, debe considerar pasar por alto los FK.
Edición: respuesta actualizada para incluir puntos de otras respuestas (informes, cascadas).
No tienes que usarlos, pero ¿por qué no lo harías?
Ellos están ahí para ayudar. Desde hacer la vida más fácil con las actualizaciones en cascada y las eliminaciones en cascada, hasta garantizar que no se violen las restricciones.
Tal vez la aplicación respeta las restricciones, pero ¿no es útil tenerlas claramente especificadas? Puede documentarlos, o puede colocarlos en la base de datos donde la mayoría de los programadores esperan encontrar restricciones a las que se supone que deben cumplir (¡una idea mejor, creo!).
Finalmente, si alguna vez necesita importar datos a esta base de datos que no se transfiere a través del front-end, puede importar accidentalmente datos que violen las restricciones y rompan la aplicación.
Definitivamente no recomendaría saltarse las relaciones en una base de datos
No usar la integridad referencial en una base de datos es como no usar los cinturones de seguridad en los automóviles. Le proporcionará mejoras mensurables en lo que le llevará de A-> B, pero hará una diferencia "real" solo en los casos más extremos. ¿Por qué tomar el "riesgo" a menos que realmente tenga que hacerlo?
La razón subyacente por la que la gente hace esta pregunta es siempre el rendimiento.
Las claves externas le dan al optimizador mucha más información para trabajar, y potencialmente producirá mejores planes de ejecución. No es como si una consulta específica fuera un% por ciento más rápida con restricciones habilitadas, es más como si eliminara de manera efectiva clases enteras de problemas debido a planes de ejecución incorrectos. También permite que el optimizador reescriba las consultas de manera que no sea posible sin las restricciones (eliminación de la unión, por ejemplo).
Comenzando aquí mismo, me gustaría comenzar el mito de que la integridad referencial siempre aumenta el rendimiento en las bases de datos. Estoy bastante seguro de que si 100 personas diseñaron sus bases de datos con una verificación de integridad completa, menos de 5 personas realmente tendrán que considerar gastar la friolera de 1 segundo para deshabilitarlas por razones de rendimiento. De esas 5 personas, habrá cerca de 0 personas que descubran que necesitan desactivar el 100% de las restricciones.
Difundir la palabra ;)
Otro punto a destacar es que cuando desecha su interfaz de usuario actual y utiliza una nueva con herramientas nuevas y brillantes, no perderá su integridad referencial porque los nuevos desarrolladores no tienen idea de qué debería relacionarse con qué. Las bases de datos generalmente se usan mucho más tiempo que las interfaces de usuario. A menudo, también son utilizadas por más de una interfaz de aplicación y, a continuación, tiene el problema de diferentes interfaces que intentan imponer diferentes reglas de integridad.
También señalaré que he tenido ocasión de ver los datos en, literalmente, cientos de bases de datos y todavía no he encontrado una que tenga buenos datos si no configuraron los FK. Esta mala información complica los informes, complica las importaciones y exportaciones hacia y desde los clientes y otros proveedores externos que necesitan o proporcionan los datos. Y si la mala información se encuentra en un área financiera, también podría tener implicaciones legales y contables. Incluso puedo recordar que una vez la compañía tuvo miles de registros de inventario incorrectos en los que el producto real que se almacenó ya no era identificable (ni tampoco la ubicación), lo que también generó problemas al definir el valor del inventario necesario para los informes financieros. Esto no solo es malo desde el punto de vista de no saber qué partes tiene a mano, sino que también permite a las personas robar piezas sin ser atrapado simplemente eliminando el número de pieza de la tabla de piezas (este lugar en particular tampoco tuvo auditoría en su lugar). .).
Si no te importa la integridad referencial, entonces tienes razón. Pero ... deberías preocuparte por la integridad referencial.
El problema es que la gente comete errores. Las computadoras no lo hacen.
Respecto a tu comentario:
Pero digamos, por ejemplo, que los programadores hacen un buen trabajo para preservar la integridad de los datos.
Alguien eventualmente cometerá un error. Nadie es perfecto. Además, si traes a alguien nuevo, no siempre estás seguro de su capacidad para escribir el código "perfecto".
Además de eso, pierde la capacidad de hacer eliminaciones en cascada y una serie de otras características que tienen claves externas definidas lo permiten.
Tal vez la pregunta debería ser "¿Qué tan malos son los registros huérfanos?". En muchos casos, los registros huérfanos no van a dañar nada. Sí, estos registros pueden persistir hasta el final de los tiempos, pero ¿qué tan grave es esto? Las actualizaciones o eliminaciones en cascada rara vez son funciones útiles. La integridad referencial suena bien, pero creo que no es tan importante como nos han hecho creer. El mayor beneficio para FK''s es la documentación que proporcionan. En mi experiencia, los FK para la integridad referencial son mucho más problemas de lo que valen.
Tu dijiste
Pero digamos, por ejemplo, que los programadores hacen un buen trabajo para preservar la integridad de los datos.
La expresión que buscaba es: "Estoy 100% seguro de que cada programador y cada administrador de base de datos conservarán manualmente la integridad de los datos a la perfección, sin importar qué aplicación toque esta base de datos, sin importar qué tan compleja sea la base de datos, desde ahora hasta el momento fuera de servicio. "
Utilice las restricciones en lugar de la lógica de la aplicación para imponer la integridad, ya que generalmente es más fácil, más barato y más confiable mantener las restricciones en un lugar (la base de datos) en lugar de en todas las aplicaciones.
Entiendo por uno de sus comentarios que su motivación para hacer la pregunta es que cree que omitir las claves puede facilitar la evolución del diseño de la base de datos durante el desarrollo. En mi experiencia te equivocas al respecto. Me parece que en realidad es mejor ser más restrictivo con restricciones en las primeras etapas de desarrollo. En caso de duda, cree la restricción porque es mucho más fácil eliminar las restricciones más tarde que crearlas. Eliminar una restricción tenderá a romper menos cosas que agregar una y generalmente requiere menos pruebas y menos cambios de código para lograr.
Las claves externas hacen la vida mucho más fácil al usar los creadores de informes y las herramientas de análisis de datos. Simplemente seleccione una tabla, marque la casilla de include related tables y BAM! usted tiene su informe construido. Ok Ok, no es tan fácil, pero ciertamente ahorran tiempo al respecto.