Cuando diseñamos grandes bases de datos relacionales, a menudo tomamos la decisión de divergir de una forma normal, es decir, desnormalización.
Las razones de esto pueden ser diferentes, como un intento de acelerar el acceso a los datos especificados, restricciones de la plataforma/marco/herramientas de desarrollo utilizadas y falta de habilidades de un desarrollador/diseñador de base de datos.
Estrictamente hablando, una referencia a las limitaciones del marco, etc. es en realidad un intento de justificar la falta de habilidades.
Los datos desnormalizados son una vulnerabilidad a través de la cual es fácil llevar nuestra base de datos a un estado no consistente (no integral).
¿Qué podemos hacer con esto?
Ejemplo
En una base de datos, hay una tabla con algunas operaciones financieras:la recepción y disposición de fondos en diferentes cuentas.
Siempre necesitamos saber el saldo de la cuenta.
En los datos normalizados, el saldo del fondo siempre es un valor calculado. Vamos a calcular el total de los recibos sin adeudar.
Sin embargo, es demasiado costoso calcular el saldo cada vez que hay muchas operaciones. Por lo tanto, se decidió almacenar el saldo real en una tabla separada. ¿Cómo actualizamos los datos de esta tabla?
La solución es 'como siempre'
Casi en todos los sistemas de información con los que tuve que trabajar, esta tarea la realizaba una aplicación externa, que implementaba la lógica de negocio. Tiene suerte si la aplicación es simple y solo hay un punto de cambio de datos, desde el formulario en la interfaz de usuario. Sin embargo, ¿qué sucede si hay algunas importaciones, API, aplicaciones de terceros, etc. realizadas por diferentes personas y equipos? ¿Qué pasa si hay varias tablas con totales en lugar de una? ¿Qué sucede si hay más de una tabla con operaciones?
Cada vez es más difícil monitorear si un desarrollador actualizó un montón de tablas al actualizar las operaciones. Los datos pierden integridad. El saldo de la cuenta no corresponde a operaciones. Por supuesto, las pruebas deben revelar tales situaciones. Sin embargo, nuestro mundo no es ideal.
Disparadores
Como alternativa, se utilizan disparadores para controlar la integridad de los datos desnormalizados.
Escuché que los activadores ralentizan mucho una base de datos, por lo que usarlos no tiene sentido.
El segundo argumento fue que toda la lógica se encuentra en una aplicación separada y mantener la lógica comercial en diferentes lugares no es razonable.
Vamos a averiguarlo.
Retrasos
Un disparador se dispara dentro de la transacción que modifica los datos en la tabla. La transacción no puede completarse hasta que el disparador haya ejecutado los pasos requeridos. Por lo tanto, la conclusión es que los desencadenantes deben ser 'ligeros'.
El ejemplo de la consulta "pesada" en el activador es el siguiente:
update totals set total = select sum(operations.amount) from operations where operations.account = current_account where totals.account = current_account
Una consulta se refiere a la tabla con operaciones y suma la cantidad total de operaciones para la cuenta .
Cuando la base de datos aumenta, dicha consulta consumirá más y más tiempo y recursos. Sin embargo, podemos recibir el mismo resultado utilizando la consulta ligera del siguiente tipo:
update totals set total = totals.total + current_amount where totals.account = current_account
Al agregar una nueva fila, este activador simplemente aumentará el total de la cuenta sin calcularlo. El total no depende de la cantidad de datos en las tablas. No tiene ningún sentido calcular el total nuevamente, ya que podemos estar seguros de que el disparador se dispara cada vez que se agrega una nueva operación.
La eliminación o modificación de filas se procesa de la misma manera. Los activadores de este tipo no ralentizarán las operaciones, sin embargo, garantizarán el acoplamiento y la integridad de los datos.
Cada vez que experimenté "retrasos" al agregar datos a una tabla con un disparador, fue un ejemplo de una consulta tan "pesada". En la mayoría de los casos, fue posible reescribirlo en una consulta "fácil".
Lógica empresarial
Debemos distinguir las funciones que proporcionan integridad de datos de la lógica empresarial. En cada caso, hago una pregunta si los datos estuvieran normalizados, ¿necesitaríamos tal función? Si es positivo, la función es lógica de negocios. Si es negativo, la función es proporcionar integridad de datos. Puede envolver estas funciones en disparadores.
Sin embargo, existe la opinión de que es fácil implementar toda la lógica empresarial a través de DBMS, como PostgreSQL u Oracle.
Espero que este artículo ayude a reducir la cantidad de errores en su sistema de información.
Por supuesto, estoy lejos de pensar que todo lo escrito aquí es la verdad última. En la vida real, por supuesto, todo es mucho más complicado. Por lo tanto, debe tomar una decisión en cada caso específico. ¡Usa tu pensamiento de ingeniería!
PD
- En el artículo, llamé la atención sobre el único aspecto del uso de disparadores como una herramienta poderosa.
- El enfoque descrito en el artículo permite evitar índices en las Operaciones que, a su vez, puede acelerar el proceso de agregar datos a esta tabla. A volúmenes altos, este enfoque compensa fácilmente el tiempo que se pasa en el gatillo.
- Es importante entender para qué herramientas necesitamos usar. En este caso, evitará muchos problemas.
