database - ¿Debería hacerse cumplir la integridad referencial?
database-design referential-integrity (11)
¡Pero Coronel Ingus, si tiene al cliente con una identificación en la sesión, ya ha sondeado la base de datos! El problema es cuando luego escribe su orden de venta, pero no la adjuntó a un producto porque no averiguó por un producto. De una forma u otra terminarás con registros huérfanos, al igual que la gran compañía con la que estoy trabajando actualmente. Tenemos clientes sin historial e historial sin clientes; clientes con saldos pendientes que nunca compraron nada y bienes vendidos a clientes que no existen, conceptos de negocios interesantes, y mantienen un equipo de personal de apoyo muy frustrado en el empleo a tiempo completo tratando de resolverlo. Sería mucho menos costoso haber puesto a RI en todo y haber comprado una caja más grande para solucionar cualquier problema de rendimiento percibido.
Una de las razones por las que la integridad referencial no debe aplicarse es el rendimiento. Debido a que Db tiene que validar todas las actualizaciones contra las relaciones, simplemente hace las cosas más lentas, pero ¿cuáles son los otros pros y contras de aplicar y no hacer cumplir?
Debido a que las relaciones se mantienen en la capa de lógica de negocios de todos modos, solo las hace redundantes para que db lo haga. que piensas de eso?
¿Qué sucede cuando intenta insertar un registro en la base de datos y falla la integridad referencial? Obtiene un error de la base de datos. Luego debe cambiar su código para que no intente insertar datos no válidos. Para evitar errores de integridad de ref, su código DEBE saber qué datos son cuáles. Por lo tanto, la integridad referencial es inútil.
Walter Mitty dijo: "Para validar la integridad referencial de un nuevo inserto, debe hacer una búsqueda en la base de datos para verificar que la referencia sea válida". Suspiro ... esto es una completa tontería. Si tengo un objeto de Cliente en la sesión (eso es memoria, también conocido como RAM para algunos de ustedes), conozco la ID del Cliente y puedo usarla para insertar un objeto SalesOrder. No hay necesidad de buscar al Cliente.
Ahora estoy en un sistema con Integridad Referencial estrecha e Hibernate envuelto alrededor de él con sus tenticles burdos. Es el sistema más lento que he visto en mi vida. No lo diseñé y, si lo tuviera, sería mucho más rápido Y más fácil de mantener. Hibernate apesta.
Depende de los datos, si sus datos altamente transaccionales, como las transacciones comerciales y las actualizaciones frecuentes, hacen que las reglas de negocio en la base de datos sean extremadamente importantes. Pero para todo lo demás, el impacto en el rendimiento puede no valer la pena.
El supuesto de rendimiento en el que se basa la pregunta es incorrecto como regla general. Por lo general, si necesita que RI se aplique, la base de datos es el lugar más eficiente para hacerlo, NO la aplicación; de lo contrario, la aplicación debe volver a solicitar más datos para poder validar la RI fuera de la base de datos.
Además, las restricciones de RI en la base de datos son útiles para el optimizador de consultas para hacer otras consultas más eficientes. Las restricciones de integridad en la aplicación no pueden lograr eso.
Por último, el costo de mantener las restricciones de integridad en cada aplicación generalmente es más costoso y complejo que hacerlo una vez en un solo lugar.
En primer lugar, es casi imposible hacer que realmente funcione correctamente. Para tener alguna posibilidad de trabajar correctamente, debe ajustar muchas de las modificaciones en cascada como transacciones, para que no tenga nada fuera de sincronización mientras ha cambiado una parte de la base de datos, pero todavía está actualizando otras que dependen de el primero. Esto significa que el código que debe ser simple y consciente solo de la lógica de negocios de repente necesita saber todo tipo de problemas de concurrencia.
En segundo lugar, mantenerlo funcionando es casi imposible de esperar: cada vez que alguien toca la lógica comercial, tienen que lidiar de nuevo con esos problemas de concurrencia.
En tercer lugar, esto hace que la integridad referencial sea difícil de entender: en el futuro, cuando alguien quiera aprender sobre la estructura de su base de datos, tendrán que aplicar ingeniería inversa de su lógica comercial. Con él en la base de datos, es independiente, por lo que lo que tiene que ver solo se ocupa de la integridad referencial, no de todo tipo de problemas no relacionados. Tiene (por ejemplo) cadenas de lógica directas que muestran qué acción provocará una modificación en un campo en particular. Al menos para bastantes bases de datos, esa lógica puede extraerse automáticamente y convertirse en documentación bastante útil (por ejemplo, diagramas de árbol que muestran dependencias). Es más probable que extraer el mismo tipo de información del BLL sea un proyecto bastante serio.
Ciertamente hay algunos puntos en la otra dirección, y razones para crear todo esto a mano: la escalabilidad y el rendimiento son los más obvios. Sin embargo, cuando / si vas por esa ruta, debes ser consciente de a lo que estás renunciando para obtener ese rendimiento. En algunos casos, es una compensación que vale la pena, pero en otros casos no lo es, y usted necesita información para tomar una decisión razonada.
La base de datos es responsable de los datos. Eso es. Período.
Si la integridad referencial no se hace en la base de datos, entonces no es integridad. Solo es confiar en que la gente no haga cosas malas, en cuyo caso probablemente ni siquiera deberías preocuparte por proteger tus datos con contraseña :-)
¿Quién puede decir que no conseguirá que alguien escriba su propio cliente conectado a JDBC para arruinar totalmente los datos, a pesar de su capa de negocio perfectamente diseñada y sin errores (el hecho de que probablemente no estará libre de errores es otro problema completamente , ordenando que el DB se proteja a sí mismo).
Las relaciones se pueden mantener en una capa de lógica de negocios. A menos que pueda garantizar 100% más que cualquier duda de que su BLL es y siempre estará libre de errores, entonces no tiene integridad de datos. Y no puedes hacer esa garantía.
Además, si otra aplicación toca su base de datos, no es necesario que siga (lea: reimplemento, quizás de una manera sutilmente incorrecta) las reglas en su BLL. Podría corromper los datos, incluso si de alguna manera logró ser uno de los 3 programadores en la Tierra para escribir código libre de errores.
Mientras tanto, la base de datos impone las mismas reglas para todos, y las reglas impuestas por la base de datos son menos propensas a pasarse por alto cuando se está actualizando, ya que el DB no lo permite.
Lo que dijeron paxdiablo y dportas. Y mis dos centavos. Hay otras dos consideraciones.
Para validar la integridad referencial de una nueva inserción, debe realizar una búsqueda en la base de datos para verificar que la referencia sea válida. Acaba de anular la ganancia de rendimiento que lo llevó a querer aplicar integridad en la aplicación. De hecho, es más rápido permitir que el SGBD haga cumplir la integridad referencial.
Más allá de eso, considere el caso donde tiene más de una aplicación, todos los datos de lectura y escritura en una única base de datos. Si aplica integridad referencial en la capa de aplicaciones comerciales, debe asegurarse de que todas las aplicaciones hagan las cosas bien. De lo contrario, alguna aplicación aberrante podría almacenar refrences inválidos, y el problema podría surgir cuando una aplicación diferente fuera a usar los datos. Eso es un verdadero desastre. Es mejor que el DBMS haga cumplir las reglas de datos para todas las aplicaciones.
Mucho se ha dicho sobre el hecho de que el DB debe ser el lugar final para validar / controlar sus restricciones (y no podría estar más de acuerdo)
Si los datos son importantes, su aplicación no será la última en acceder a la base de datos y no será la única.
Pero hay otro hecho muy importante sobre la integridad referencial (y otras restricciones): documenta su modelo de datos y hace explícitas las dependencias entre las tablas.
En lo que respecta al rendimiento, la definición de FK (u otras restricciones) en la base de datos puede hacer que las cosas sean aún más rápidas en ciertos casos, porque el DBMS puede confiar en las restricciones y realizar las optimizaciones adecuadas.
Si mantiene las relaciones en la capa de negocios, puede garantizar que dentro de unos pocos años tendrá datos incorrectos en la base de datos. La capa de negocios es el peor lugar posible para hacer eso.
Además, cuando reemplazas la capa de negocios con otra cosa, tienes que redefinir todas estas cosas. Las bases de datos a menudo duran más que la aplicación original para la que están escritas durante muchos años, colocan las realidades y limitaciones correctas en la base de datos a la que pertenecen.
listen a Dan Pritchett, Technical Fellow en eBay, sobre por qué ciertas construcciones de bases de datos, como las transacciones y la integridad referencial, no son los mandatos que los libros de texto pueden indicar que deberían ser ... Todo se reduce a los tipos de datos, el volumen de consultas y requisitos comerciales Equilibre esos y le conducirá a soluciones pragmáticas, no respuestas dogmáticas ...
Sin embargo, no asuma que mantener relaciones en el BLL protegerá sus datos. No se puede garantizar que los futuros desarrolladores no expongan nuevas API que eludan el BLL por razones de "rendimiento" o por simple desconocimiento de su arquitectura ...