database - tool - data model español
Restricciones de base de datos: ¿mantener o ignorar? (10)
Bueno, es cierto que existen muy pocas verdades definitivas, y también es cierto que muchos productos de éxito comercial evitan la integridad referencial declarada (DRI).
Por otro lado, si le preocupan los datos en su base de datos, casi no hay mejor manera de salvaguardar la integridad de esos datos que a través de DRI.
Si lo deja todo hasta el código en la parte superior, está confiando en que nadie accederá a la base de datos por otros medios. Si lo hacen, no habrá nada que detenga la corrupción de datos (filas huérfanas, datos inconsistentes e ilógicos).
Cuando estaba aprendiendo en la universidad, nos enseñaron los fundamentos, los conceptos básicos y las reglas de la base de datos, y una de las reglas más importantes son las restricciones (clave principal, clave externa) y cómo establecer relaciones de 1-m, 1-1, mn. .
Ahora, cuando me mudo a un entorno empresarial real, me dicen: debes olvidar todo lo que te han enseñado; sin restricciones, todas esas relaciones son lógicas, sin claves primarias, sin claves externas, puede establecer sus restricciones a través del código.
No sé quién tiene razón: lo que aprendí en mi vida académica o lo que aprenderé en mi nueva vida empresarial real. ¿Qué piensas?
Creo que las restricciones te ayudan a tener datos limpios. El rendimiento a veces se mejora. En algunos casos, el rendimiento puede verse afectado por las restricciones. Sin embargo, la respuesta a eso no es eliminar las restricciones. Tiene algo llamado "desnormalización" para ayudarlo a lidiar con los problemas de rendimiento (siempre que sus consultas ya estén optimizadas). Siempre puede crear tablas de resumen desnormalizadas en dichos escenarios.
¿Los tipos que te dijeron que "olvidaste lo que aprendiste" también te dijeron que habían olvidado las reglas de tráfico que aprendieron en las clases de manejo?
Cuando estaba en clase, accedimos a tablas con SQL sin formato, y hay un montón de SQL sin formato o su equivalente por ahí. En estos casos, las restricciones son generalmente buenas.
Sin embargo, hay sistemas que utilizan las bases de datos como back-end, y solo un sistema de software en particular puede acceder a estas bases de datos. En este caso, el software debe realizar un seguimiento de las relaciones y restricciones necesarias, y la base de datos sirve como un control redundante que no proporciona una buena respuesta y reduce el rendimiento.
Las restricciones de la base de datos son redundantes porque el sistema adjunto necesita mantener las restricciones en sí. La retroalimentación es que se violó una cierta restricción de base de datos. Si un programa es capaz de lidiar con tal retroalimentación, es capaz de hacer sus propios controles. El costo de rendimiento debe ser obvio.
Las restricciones aún pueden ser útiles en los sistemas de desarrollo o prueba, pero cuando el sistema entra en producción casi todo lo que pueden hacer es bloquear el sistema si algo sale mal, y eso es generalmente lo que no quiere que suceda en un sistema grande como ese.
Cuanto más tiempo trabajo con bases de datos, más aprecio las restricciones. A la larga, me ahorran mucho tiempo. Solo restricciones confiables aseguran el 100% de validez de los datos.
Escribí un capítulo sobre el uso de restricciones frente a otras formas de garantizar la integridad de los datos, disponible como descarga gratuita here
He pasado mucho tiempo arreglando los datos de mierda producidos por los incompetentes que creen que las restricciones pertenecen al código de la aplicación. Si una base de datos está diseñada sin estos elementos requeridos, tendrá datos erróneos. Haga una revisión rápida de cualquier sistema como este que haya estado funcionando durante varios años y encontrará registros huérfanos y la información requerida que falta, etc.
Las claves primarias son importantes Necesitas una forma única de identificar las filas.
Pero, según mi experiencia, si encapsula correctamente el acceso a su base de datos dentro de las clases (es decir, leyendo / escribiendo objetos a / desde la base de datos), las restricciones no son generalmente necesarias. Sí, podría usarlas si 50 aplicaciones diferentes en 10 idiomas diferentes estuvieran usando la misma base de datos. Pero si es una aplicación, o un conjunto común de aplicaciones que comparten una base de código fuente, prefiero tener toda la lógica de manipulación de la base de datos en un lugar para hacer que la aplicación sea más fácil de mantener. Lo mismo ocurre con los procedimientos almacenados, pero tienen el problema adicional de la portabilidad entre los sistemas de base de datos si escribe el código destinado a manejar una amplia variedad de bases de datos.
Las restricciones de la base de datos son una gran idea cuando tiene usuarios que acceden a la base de datos a quienes pueden dañar sus datos (es decir, a cualquier usuario). Tiendo a mantener las restricciones de clave externa en su lugar para asegurarme de que cualquier persona que edite datos en mi base de datos es consciente de que otras tablas se basan en los datos de la tabla actual.
Lo que aprendiste no es solo cosas académicas. Pero sí , es como la utopía de Platón a veces . Es la condición perfecta en la que puede estar su base de datos, el diseño ideal. Pero ese diseño ideal no siempre es posible.
Las restricciones deben estar lo más cerca posible de los datos de DB. Piensa en ello de esta manera. ¿Qué sucede si escribió sus restricciones en el código y luego quiso migrar a un idioma / plataforma diferente y surgió un error en una de sus restricciones? Sería desastroso. Cosas como PK, FK, restricciones, etc. se utilizan ampliamente. Han sido utilizados por más de 30 años. Entonces, no son basura, pero en ciertos escenarios simplemente no son manejables. Por ejemplo, si eres Google, no puedes simplemente confiar en un modelo relacional para dar respuestas en milisegundos.
Por lo tanto, en función de los requisitos como la velocidad y la estabilidad, a veces también duplicamos datos, no usamos PK o no establecemos relaciones, etc. Pero solo cuando buscamos algo específico Y cuando sabemos lo que perderemos haciéndolo de esa manera.
Al final, el modelo relacional sigue siendo solo un modelo. Es una forma de representar las cosas. Es una forma muy exitosa, pero no es una bendición, por lo que en algunos casos debe comprometerse.
Si alguien me dijera que ignore las claves y restricciones de mis bases de datos, las ignoraría de inmediato y me ocuparía de mi negocio.
Las claves primarias, las claves externas y las restricciones están ahí por una razón. Usalos, usalos a ellos. Te harán la vida más fácil y tu base de datos más fácil de entender (y, con bastante frecuencia, más eficaz).
Si piensa que las restricciones se limitan a las claves primarias y externas, entonces, de hecho, no se le ha enseñado gran parte de los "fundamentos".
Le sugiero que eche un vistazo a "Una introducción a la teoría de la base de datos relacional" de Hugh Darwen, que está disponible gratuitamente en línea. Y al menos obtienes una educación genuina sobre los "fundamentos" de eso.