¿Son realmente necesarias las claves externas en el diseño de una base de datos?

https://stackoverflow.com/questions/18717

09-06-2019
|

Pregunta

Hasta donde yo sé, las claves externas (FK) se utilizan para ayudar al programador a manipular los datos de la manera correcta.Supongamos que un programador ya está haciendo esto de la manera correcta, entonces ¿realmente necesitamos el concepto de claves externas?

¿Existen otros usos para las claves externas?¿Me estoy perdiendo de algo?

Solución

Las claves externas ayudan a imponer la integridad referencial a nivel de datos.También mejoran el rendimiento porque normalmente están indexados de forma predeterminada.

Otros consejos

Las claves externas también pueden ayudar al programador a escribir menos código usando cosas como ON DELETE CASCADE.Esto significa que si tiene una tabla que contiene usuarios y otra que contiene pedidos o algo así, eliminar un usuario podría eliminar automáticamente todos los pedidos que apuntan a ese usuario.

No me imagino diseñando una base de datos sin claves externas.Sin ellos, eventualmente cometerá un error y corromperá la integridad de sus datos.

Ellos no son requerido, estrictamente hablando, pero los beneficios son enormes.

Estoy bastante seguro de que nieblabugz no tiene restricciones de clave externa en la base de datos.Me interesaría saber cómo Software de niebla Creek El equipo estructura su código para garantizar que nunca introducirán una inconsistencia.

Un esquema de base de datos sin restricciones FK es como conducir sin cinturón de seguridad.

Un día te arrepentirás.No dedicar ese poco de tiempo extra a los fundamentos del diseño y la integridad de los datos es una forma segura de evitar dolores de cabeza en el futuro.

¿Aceptarías un código en tu aplicación que fuera tan descuidado?Eso accedió directamente a los objetos miembro y modificó las estructuras de datos directamente.

¿Por qué crees que esto se ha vuelto difícil y incluso inaceptable dentro de las lenguas modernas?

Sí.

Te mantienen honesto
Mantienen a los nuevos desarrolladores honestos
Tu puedes hacer ON DELETE CASCADE
Te ayudan a generar bonitos diagramas que explican por sí solos los vínculos entre tablas.

Personalmente, estoy a favor de las claves foráneas porque formaliza la relación entre las tablas.Me doy cuenta de que su pregunta presupone que el programador no está introduciendo datos que violarían la integridad referencial, pero he visto demasiados casos en los que se viola la integridad referencial de los datos, ¡a pesar de las mejores intenciones!

Antes de las restricciones de clave externa (también conocidas como integridad referencial declarativa o DRI), se dedicó mucho tiempo a implementar estas relaciones mediante activadores.El hecho de que podamos formalizar la relación mediante una restricción declarativa es muy poderoso.

@John: otras bases de datos pueden crear automáticamente índices para claves externas, pero SQL Server no.En SQL Server, las relaciones de clave externa son sólo restricciones.Debe definir su índice de claves externas por separado (lo que puede resultar beneficioso).

Editar:Me gustaría agregar que, en mi opinión, el uso de claves externas para admitir ON DELETE o ON UPDATE CASCADE no es necesariamente algo bueno.En la práctica, he descubierto que la eliminación en cascada debe considerarse cuidadosamente en función de la relación de los datos, p.¿Tiene un padre-hijo natural donde esto puede estar bien o la tabla relacionada es un conjunto de valores de búsqueda?El uso de actualizaciones en cascada implica que permite modificar la clave principal de una tabla.En ese caso, tengo un desacuerdo filosófico general en el sentido de que la clave principal de una tabla no debería cambiar.Las claves deben ser inherentemente constantes.

Supongamos que un programador ya está haciendo esto de la manera correcta.

Hacer tal suposición me parece una idea extremadamente mala;en general, el software tiene muchos errores.

Y ese es el punto, realmente.Los desarrolladores no pueden hacer las cosas bien, por lo que asegurarse de que la base de datos no se llene con datos incorrectos es algo bueno.

Aunque en un mundo ideal, las uniones naturales utilizarían relaciones (es decir,restricciones FK) en lugar de hacer coincidir los nombres de las columnas.Esto haría que los FK fueran aún más útiles.

Sin una clave externa, ¿cómo se puede saber que dos registros en tablas diferentes están relacionados?

Creo que a lo que te refieres es a la integridad referencial, donde no se permite crear el registro secundario sin un registro principal existente, etc.A menudo se las conoce como restricciones de clave externa, pero, en primer lugar, no deben confundirse con la existencia de claves externas.

¿Existe algún beneficio por no tener claves externas?A menos que esté utilizando una base de datos deficiente, los FK no son tan difíciles de configurar.Entonces, ¿por qué tendrías una política de evitarlos?Una cosa es tener una convención de nomenclatura que diga que una columna hace referencia a otra y otra es saber que la base de datos realmente está verificando esa relación por usted.

Supongo que estás hablando de Restricciones de clave externa impuestas por la base de datos..Probablemente ya esté utilizando claves externas, pero no se lo ha informado a la base de datos.

Supongamos que un programador ya está haciendo esto de la manera correcta, ¿realmente necesitamos el concepto de claves extranjeras?

En teoría, no.Sin embargo, nunca ha habido un software sin errores.

Los errores en el código de la aplicación generalmente no son tan peligrosos: usted identifica el error y lo corrige, y luego la aplicación vuelve a ejecutarse sin problemas.Pero si un error permite que datos corruptos entren en la base de datos, ¡entonces te quedarás atrapado!Es muy difícil recuperarse de datos corruptos en la base de datos.

Considere si hay un error sutil en nieblabugz permitió que se escribiera una clave externa corrupta en la base de datos.Puede ser fácil corregir el error y enviar rápidamente la solución a los clientes en una versión de corrección de errores.Sin embargo, ¿cómo deberían repararse los datos corruptos en docenas de bases de datos? Correcto El código ahora podría romperse repentinamente porque las suposiciones sobre la integridad de las claves externas ya no se mantienen.

En las aplicaciones web normalmente sólo hay un programa que se comunica con la base de datos, por lo que sólo hay un lugar donde los errores pueden dañar los datos.En una aplicación empresarial puede haber varias aplicaciones independientes que se comunican con la misma base de datos (sin mencionar las personas que trabajan directamente con el shell de la base de datos).No hay forma de estar seguro de que todas las aplicaciones sigan los mismos supuestos sin errores, siempre y para siempre.

Si las restricciones están codificadas en la base de datos, entonces lo peor que puede pasar con los errores es que al usuario se le muestre un feo mensaje de error sobre algunos. SQL restricción no satisfecha.Esto es mucho Es preferible dejar que los datos corruptos entren en su base de datos empresarial, donde a su vez dañarán todas sus aplicaciones o simplemente conducirán a todo tipo de resultados incorrectos o engañosos.

Ah, y las restricciones de clave externa también mejoran el rendimiento porque están indexadas de forma predeterminada.No puedo pensar en ninguna razón no utilizar restricciones de clave externa.

Los FK son muy importantes y siempre deben existir en su esquema, a menos que seas eBay.

Creo alguna sola cosa en algún momento debe ser responsable de garantizar relaciones válidas.

Por ejemplo, Ruby on Rails No utiliza claves foráneas, pero valida todas las relaciones por sí mismo.Si sólo accede a su base de datos desde esa aplicación Ruby on Rails, está bien.

Sin embargo, si tiene otros clientes que escriben en la base de datos, sin claves externas deberán implementar su propia validación.Luego tiene dos copias del código de validación que probablemente sean diferentes, lo que cualquier programador debería poder decir que es un pecado capital.

En ese punto, las claves externas son realmente necesarias, ya que le permiten trasladar la responsabilidad a un único punto nuevamente.

Las claves externas permiten que alguien que no haya visto su base de datos antes determine la relación entre las tablas.

Puede que todo esté bien ahora, pero piensa en lo que pasará cuando tu programador se vaya y alguien más tenga que hacerse cargo.

Las claves externas les permitirán comprender la estructura de la base de datos sin tener que rastrear miles de líneas de código.

Hasta donde yo sé, las claves externas se utilizan para ayudar al programador a manipular los datos de la manera correcta.

Los FK permiten al DBA proteger la integridad de los datos de las torpezas de los usuarios cuando el programador falla para hacerlo y, a veces, para protegerse contra las torpezas de los programadores.

Supongamos que un programador ya está haciendo esto de la manera correcta, entonces ¿realmente necesitamos el concepto de claves externas?

Los programadores son mortales y falibles.Los FK son declarativo lo que los hace más difíciles de arruinar.

¿Existen otros usos para las claves externas?¿Me estoy perdiendo de algo?

Aunque esta no es la razón por la que fueron creados, los FK brindan sugerencias sólidas y confiables para las herramientas de diagramación y los creadores de consultas.Esto se transmite a los usuarios finales, que necesitan desesperadamente sugerencias sólidas y fiables.

No son estrictamente necesarios, como tampoco lo son los cinturones de seguridad.Pero realmente pueden evitar que hagas algo estúpido que arruine tu base de datos.

Es mucho mejor depurar un error de restricción FK que tener que reconstruir una eliminación que rompió su aplicación.

Son importantes porque su aplicación no es la única forma en que se pueden manipular los datos en la base de datos.Su aplicación puede manejar la integridad referencial tan honestamente como quiera, pero todo lo que necesita es que un idiota con los privilegios adecuados venga y emita un comando de inserción, eliminación o actualización a nivel de base de datos, y se omitirá toda la aplicación de la integridad referencial de su aplicación.Poner restricciones FK en el nivel de la base de datos significa que, salvo que este bozo elija deshabilitar la restricción FK antes de emitir su comando, la restricción FK provocará que una declaración de inserción/actualización/eliminación incorrecta falle con una violación de integridad referencial.

Lo pienso en términos de costo/beneficio...En mysql, agregar una restricción es una sola línea adicional de DDL.Son sólo un puñado de palabras clave y un par de segundos de reflexión.Ese es el único "coste" en mi opinión...

A las herramientas les encantan las claves externas.Las claves externas evitan que los datos incorrectos (es decir, filas huérfanas) no afecten la lógica o la funcionalidad empresarial y, por lo tanto, pasen desapercibidos y se acumulen.También evita que los desarrolladores que no están familiarizados con el esquema implementen porciones enteras de trabajo sin darse cuenta de que les falta una relación.Quizás todo sea excelente dentro del alcance de su aplicación actual, pero si se perdió algo y algún día se agrega algo inesperado (piense en informes sofisticados), es posible que se encuentre en una situación en la que tenga que limpiar manualmente los datos incorrectos que se han estado acumulando desde el inicio. del esquema sin una verificación obligatoria de la base de datos.

El poco tiempo que lleva codificar lo que ya tienes en la cabeza cuando estás armando las cosas podría ahorrarte a ti o a otra persona un montón de dolores de cabeza durante meses o años.

La pregunta:

¿Hay otros usos para las claves extranjeras?¿Me estoy perdiendo de algo?

Está un poco cargado.Inserte comentarios, sangrías o nombres de variables en lugar de "claves externas"...Si ya comprende perfectamente el tema en cuestión, "no le sirve de nada".

Reducción de entropía.Reducir la posibilidad de que ocurran escenarios caóticos en la base de datos.Nos cuesta mucho considerar todas las posibilidades, por lo que, en mi opinión, la reducción de entropía es clave para el mantenimiento de cualquier sistema.

Cuando hacemos una suposición, por ejemplo:cada pedido tiene un cliente y esa suposición debe ser cumplida por algo.En las bases de datos ese "algo" son las claves externas.

Creo que vale la pena compensar la velocidad de desarrollo.Claro, puedes codificar más rápido sin ellos y probablemente esta sea la razón por la que algunas personas no los usan.Personalmente he matado varias horas con NHibernate y alguna restricción de clave externa que se enoja cuando realizo alguna operación.SIN EMBARGO, sé cuál es el problema, por lo que es un problema menor.Estoy usando herramientas normales y hay recursos que me ayudan a solucionar este problema, ¡posiblemente incluso personas que me pueden ayudar!

La alternativa es permitir que un error se introduzca en el sistema (y con el tiempo suficiente, lo hará) cuando no se establece una clave externa y sus datos se vuelven inconsistentes.Luego, recibe un informe de error inusual, investiga y dice "OH".La base de datos está jodida.¿Cuánto tiempo llevará arreglarlo?

Puede ver las claves externas como una restricción que,

Ayude a mantener la integridad de los datos
Mostrar cómo se relacionan los datos entre sí (lo que puede ayudar a hacer cumplir la lógica y las reglas empresariales)
Si se usa correctamente, puede ayudar a aumentar la eficiencia con la que se obtienen los datos de las tablas.

Actualmente no utilizamos claves externas.Y en general no nos arrepentimos.

Dicho esto, es probable que comencemos a usarlos mucho más en el futuro cercano por varias razones, ambas similares:

Diagramación.Es mucho más fácil producir un diagrama de una base de datos si se utilizan correctamente las relaciones de clave externa.
Soporte de herramientas.Es mucho más fácil construir modelos de datos usando estudio visual 2008 que se puede utilizar para LINQ a SQL si existen relaciones de clave externa adecuadas.

Así que supongo que lo que quiero decir es que hemos descubierto que si estamos haciendo mucho trabajo SQL manual (construcción de consulta, ejecución de consulta, blablabla), las claves foráneas no son necesariamente esenciales.Sin embargo, una vez que empiezas a utilizar las herramientas, se vuelven mucho más útiles.

Lo mejor de las restricciones de clave externa (y de las restricciones en general, en realidad) es que puede confiar en ellas al escribir sus consultas.Muchas consultas pueden volverse mucho más complicadas si no puede confiar en que el modelo de datos sea "verdadero".

En el código, generalmente obtendremos una excepción en alguna parte, pero en SQL, generalmente obtendremos respuestas "incorrectas".

En teoria, Servidor SQL Podría usar restricciones como parte de un plan de consulta, pero a excepción de las restricciones de verificación para la partición, no puedo decir que alguna vez haya sido testigo de eso.

Las claves externas nunca habían sido explícitas (tabla (columna) de REFERENCIAS DE CLAVE EXTRANJERA) declaradas en proyectos (aplicaciones comerciales y sitios web de redes sociales) en los que trabajé.

Pero siempre hubo una especie de convención para nombrar columnas que eran claves externas.

es como con normalización de base de datos - tienes que saber qué estás haciendo y cuáles son las consecuencias de ello (principalmente el rendimiento).

Soy consciente de las ventajas de las claves externas (integridad de los datos, índice para la columna de clave externa, herramientas que conocen el esquema de la base de datos), pero también tengo miedo de usar claves externas como regla general.

Además, varios motores de bases de datos podrían proporcionar claves externas de forma diferente, lo que podría provocar errores sutiles durante la migración.

Eliminar todos los pedidos y facturas del cliente eliminado con ON DELETE CASCADE es el ejemplo perfecto de un esquema de base de datos atractivo, pero mal diseñado.

Sí.ON DELETE [RESTRICT|CASCADE] evita que los desarrolladores dejen datos varados, manteniéndolos limpios.Recientemente me uní a un equipo de desarrolladores de Rails que no se centraban en las restricciones de la base de datos, como las claves externas.

Por suerte encontré estos: http://www.redhillonrails.org/foreign_key_associations.html -- Los complementos de RedHill en Ruby on Rails generan claves externas utilizando el Convención sobre configuración estilo.Una migración con ID del Producto creará una clave externa para el identificación en el productos mesa.

Echa un vistazo a los otros fantásticos complementos en Colina roja, incluidas las migraciones envueltas en transacciones.

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

No afiliado a StackOverflow