¿Tendría alguna vez sentido que la aplicación haga cumplir la integridad de la base de datos en lugar de tener claves externas, verificar restricciones, etc.?
¿Cuánto de una mejora de rendimiento se puede esperar por no hacer cumplir la integridad de la base de datos a través de herramientas internas de la base de datos?
Respuestas:
A decir verdad, no solo no verá mucha pérdida de rendimiento por tener restricciones de clave externa en la base de datos, sino que verá mejoras de rendimiento. El optimizador de consultas de SQL Server se basa en el concepto de claves primarias y externas, así como en otros tipos de restricciones de datos. Si estos están implementados y aplicados, el optimizador puede aprovecharlos para obtener un mejor rendimiento. Aquí hay una publicación de blog con un ejemplo simple que lo muestra en acción.
Si se encuentra en un caso extremo donde realmente tiene más inserciones que lecturas (y las actualizaciones y eliminaciones requieren lecturas, por lo que generalmente terminan agregando al recuento de lecturas), entonces podría tener sentido eliminar las restricciones de los datos para el rendimiento, tal vez . Pero como la gran mayoría de las bases de datos están orientadas a la lectura, está sacrificando el rendimiento, no mejorando.
Y nada de esto menciona el hecho de que la integridad de los datos se maneja mejor en la base de datos, ya que solo tiene que crearla una vez y, como si hiciera todo el trabajo en código, es posible que tenga que hacerlo varias veces para múltiples aplicaciones (a menos que diseñe su capa de acceso a datos con cuidado y requiere que cada aplicación acceda a la base de datos para pasar por esa misma capa).
Si está utilizando un sistema de base de datos relacional, digo, ¿por qué no usarlo realmente? Si no necesita datos relacionales, vaya con Hadoop u otra cosa.
Muchos desarrolladores de aplicaciones piensan que sí.
Cuando sienta la tentación de delegar la integridad de los datos en el código de la aplicación, piense: "Cada programador y cada aplicación que llegue a esta base de datos desde ahora hasta el final de los tiempos tiene que hacerlo perfectamente bien, siempre".
¿Cuáles son las probabilidades?
Incluso si hay alguna ganancia de rendimiento, es insignificante en comparación con el retorno de la integridad referencial y la integridad de datos generalizada.
Atrás quedaron los días en que una base de datos es un almacén de datos tonto. Aproveche el poder que ofrece RDBMS.
Las ganancias de rendimiento no lo son todo, especialmente en una escala tan pequeña como esta. Pero cuando descubra que tiene una supuesta relación de clave externa que se supone que su aplicación debe aplicar, y resulta que no es una clave principal en la tabla de referencia, entonces le importará muy poco la ganancia de rendimiento (si la hay, puedo No hablemos de los detalles de eso).
Es una práctica común eliminar restricciones (claves foráneas, CHECK, etc.) e índices si está haciendo una carga de datos lo suficientemente grande, y luego volver a habilitar / implementar las restricciones e índices. Esa validación tiene un costo de tiempo. Eso supone que no puede usar la sintaxis de carga masiva específica de la base de datos (incluida la minimización del registro).
Es imposible decir cuánto espera un aumento de rendimiento: cada situación es única (tipos de datos, diseño, etc.). La única forma de saber realmente es probar.
Hay algunas ocasiones en que las restricciones se interponen en el camino:
Cuando necesita usar herencia de tabla única (ITS). Imagine que vende a individuos y organizaciones. Necesitará una sola tabla "Party" cuya fila sea individual o de una organización. STI significa que necesita algunos campos anulables que no deberían ser nulos. La herencia de tablas de clase resuelve esto, pero esto es más difícil para algunos ORM. ActiveRecord de Ruby solo admite STI, por ejemplo.
Cuando necesite admitir versiones Borrador de una entidad, eso puede no ser completamente válido. Puede almacenar un borrador como json, pero luego es más difícil reutilizar el mismo identificador en el cliente; imagine que se ha guardado con id = 5, editado para que no sea válido y guardado automáticamente como draftid = 99. En este caso, todos sus campos probablemente tendrían que ser anulables.