Pros y contras de aplicar programáticamente una clave externa que en la base de datos

Question

Está causando tantos problemas en términos de desarrollo simplemente dejando que la base de datos aplique la clave externa. Especialmente durante la prueba unitaria no puedo abandonar la tabla debido a restricciones de clave externa, necesito crear una tabla en un orden tal que la advertencia de restricción de clave externa no se active. En realidad, no veo demasiado el punto de dejar que la base de datos haga cumplir las restricciones de clave foránea. Si la aplicación se ha diseñado correctamente, no debe haber ninguna manipulación manual de la base de datos que no sea la de seleccionar consultas. Solo quiero asegurarme de que no me estoy metiendo en un agujero al no tener limitaciones de clave externa en la base de datos y dejarlo únicamente a la responsabilidad de la aplicación. ¿Me estoy perdiendo algo?

P.S. mis pruebas unitarias reales (no las que usan burlas) eliminarán las tablas existentes si la estructura del objeto de dominio subyacente ha sido modificada.

Answer 1

En mi experiencia, si no aplica llaves foráneas en una base de datos, eventualmente (suponiendo que la base de datos es relativamente grande y muy utilizada) terminará con registros huérfanos. Esto puede suceder de muchas maneras, pero siempre parece suceder.

Si indiza correctamente, no debería haber ninguna ventaja de rendimiento para las claves externas.

Entonces, la pregunta es, ¿el daño potencial/molestia/costo de soporte/costo financiero de tener registros huérfanos en su base de datos supera el desarrollo y la molestia de las pruebas?

En mi experiencia, para aplicaciones comerciales siempre uso claves foráneas. Solo debe ser un costo de instalación único para que sus scripts de compilación funcionen correctamente, y la estabilidad de los datos será más que suficiente durante la vida de una aplicación.

Answer 2

El objetivo de hacer cumplir las reglas en la base de datos es que es declarativo, p. no es necesario escribir toneladas de código para manejarlo.

En cuanto a las pruebas de su unidad, simplemente elimine las tablas en el orden correcto. Solo tienes que escribir una función para hacerlo bien una vez.

Answer 3

Aquí hay una buena discusión sobre eso en una pregunta anterior en SO: What's wrong with foreign keys?. [Editar]: El argumento es hacer que las claves foráneas no forzadas obtengan algunos de los pros si se aplica alguno de los inconvenientes.

Answer 4

Puede parecer que puede confiar en que sus aplicaciones seguirán las reglas implícitas, pero a menos que las haga valer, eventualmente alguien se equivocará.
O tal vez dentro de 5 años alguien hará una limpieza de los registros antiguos "que ya no son necesarios" y no se dará cuenta de que hay datos en otras tablas que todavía hacen referencia a ellos. Luego, unos días/semanas más tarde, usted o su sucesor obtienen el divertido trabajo de intentar reparar el desastre que ha tenido la base de datos. :-)

Answer 5

Sus problemas en el desarrollo no deberían impulsar el diseño de la base de datos. La reconstrucción constante de un DB es un caso de uso del desarrollador, no un caso de uso del cliente.

Además, las limitaciones de la base de datos ayudan más allá de su aplicación. Nunca se sabe lo que su cliente podría intentar hacer. No lo hagas en exceso, pero necesitas algunos.

Answer 6

Si la solicitud ha sido correctamente diseñó no debería haber ninguna la manipulación manual de la base de datos de otra consultas de selección

¿Qué? ¿Qué tipo de koolaid estás bebiendo?La mayoría de las aplicaciones de bases de datos existen para manipular los datos en la base de datos no solo para verlos. En general, el propósito de la aplicación es agregar nuevos pedidos o crear nuevos registros de clientes o documentar las llamadas de servicio al cliente, etc.

Las claves externas son para la integridad de los datos. La integridad de los datos es fundamental para poder utilizar los datos con cualquier fiabilidad. Las bases de datos sin integridad de datos son inútiles y pueden causar que las empresas pierdan dinero. Esto supera su visión egocéntrica de que los FK no son necesarios porque hacen que el desarrollo sea más complicado para usted. Los datos son mucho más importantes que su conveniencia en la ejecución de pruebas (que se pueden escribir en la cuenta para los FK).