¿El saldo de la cuenta del usuario debe almacenarse en la base de datos o calcularse dinámicamente?

¿El saldo de la cuenta del usuario debe almacenarse en la base de datos o calcularse dinámicamente?

Para que los resultados precisos, el cálculo dinámicamente tenga sentido, pero entonces podría ser un problema, cuando hay muchos usuarios y la base de datos crece mucho.

Transacción

  • Id (PK)
  • ID de la cuenta
  • Tipo
  • Fecha y hora
  • Cantidad
  • etcétera etcétera…

Saldo de la cuenta

  • TransactionId (PK / FK)
  • Balance total

Para mantener una auditoría precisa, debe registrar todas las transacciones que afecten el saldo de la cuenta de los usuarios. Esto significa que puede calcular el saldo dinámicamente, sin embargo, por razones de rendimiento, también se almacenaría el saldo. Sin embargo, para garantizar que el saldo sea correcto, tendría un trabajo diario que recalcula el saldo desde cero.

Creo que esta es una buena pregunta. Calcular cada vez es obviamente fácil de hacer, pero probablemente resultaría en una gran cantidad de cálculos innecesarios con el impacto de rendimiento resultante.

Pero el almacenamiento del saldo actual en alguna otra tabla puede llevar a problemas en la concurrencia de datos, donde los datos en los que se construye el agregado se modifican fuera de sincronización con el agregado.

Quizás un medio feliz es tener un desencadenante de SQL en la tabla de transacciones que actualiza el valor agregado en una inserción o actualización para ese usuario.

Debe hacerse algunas preguntas: 1) ¿A QUIÉN SERÁ PROPIETARIO del cálculo? 2) ¿Quién NECESITA el resultado?

Ahora, si el propietario del cálculo es el único que lo necesitará, o si alguien más lo necesita lo obtendrá del propietario, entonces no es necesario almacenar el cálculo.

Sin embargo, en la mayoría de las aplicaciones que realmente se ejecutan durante mucho tiempo, el resultado calculado probablemente se necesitará en otro lugar. Por ejemplo, una aplicación de informes como SQLReportingServices necesitará el resultado del cálculo, por lo que si el propietario del cálculo es una aplicación web, tiene un problema. ¿Cómo obtendrán el servicio los servicios de informes (que solo hablan con la base de datos)?

Solución en ese caso: almacene el cálculo O haga que la base de datos sea el propietario del cálculo y tenga una función SQL que devuelva el resultado.

Personalmente, tiendo a optar por el enfoque no purista: almaceno los resultados calculados en la base de datos. El espacio es barato y el tiempo de respuesta es más rápido en una lectura que en una llamada de función de lectura.

¡El saldo actual ya está disponible! Es el saldo en la última transacción de la cuenta:

select top 1 [Balance] from dbo.Trans where [AccountID] = @AccountID order by [TranID] desc 

el saldo debe calcularse y almacenarse como parte de cada transacción; de lo contrario, el sistema no se escalará … también, si no almacena el saldo, no tendrá cheques y saldos (el saldo debe ser igual al saldo anterior más los créditos nuevos menos) nuevos débitos)

  1. Si su aplicación no está recuperando datos de la base de datos para el cálculo del saldo mientras necesita el saldo, le sugeriré que calcule el saldo o que almacene en la base de datos.

  2. Si necesita un saldo actualizado con frecuencia y se modifica dinámicamente según más de una tabla, debe tener una vista de tabla en lugar de un activador.