La mejor manera de mantener el saldo de una cuenta de cliente

Question

¿Es mejor tener un campo en la base de datos que almacene el saldo de la cuenta de los clientes o usar vistas y consultas para generar la información?

Answer 1

Para el rendimiento, diría que ambos. Mantenga un registro de todas las transacciones (en una tabla separada) pero mantenga un campo en el registro del cliente que almacena el saldo actual que se actualiza cuando agrega más transacciones.

Answer 2

Creo que esto depende de muchos factores, con qué frecuencia accederá a la balanza, qué tan complejo es volver a calcularla cada vez que la necesite. ¿Cuáles son los gastos generales de tener vistas, etc.

Puramente en la cara de la información que ha proporcionado, yo almacenaría el valor, ya que recalcularlo desde cero cada vez podría ser un problema.

Answer 3

Si las vistas y las consultas le dan un resultado lo suficientemente rápido, entonces no almacene en un campo separado.

Si no es lo suficientemente rápido, guárdelo en un campo aparte. Como este campo almacenará información redundante, es muy importante mantenerlo sincronizado.

Answer 4

Eso sería una función de la frecuencia con la que necesita acceder a esta información. Si es de vez en cuando, entonces le digo que continúe y vuelva a calcularlo.

Answer 5

Un proyecto en el que trabajé almacenamos el saldo actual en un campo y todas las transacciones en otra tabla, pero debido al nivel de importancia que este proyecto tenía en los datos siendo perfecto 100% (o mejor) o tiempo, también almacenamos un hash de la balanza en otro campo y el hash se comparó cada vez que se llamó para garantizar la integridad; si no coincidía, se recalculó de la tabla de transacciones y se volvió a codificar y luego se envió al cliente departamento de soporte para la revisión.

Answer 6

Use las vistas y las consultas; le sorprendería saber qué tan rápido se ejecutará.

Answer 7

"Depende". La mayoría de las veces, desea evitar los datos derivados. Sin embargo, hay casos donde tener el total derivado está justificado.

Caso en cuestión:

que trabajó en una aplicación de base de datos de crédito, donde el equilibrio se compone de muchas cosas diferentes, y diferentes reglas de negocio a través del tiempo. Por ejemplo, el "saldo" era en realidad una suma de diferentes saldos de diferentes segmentos, como Principal, Honorarios, etc.

A medida que se contabilizaban las transacciones, se asignaban a diferentes depósitos de acuerdo con las reglas comerciales. Los honorarios fueron al canon de las tarifas. Las compras, los créditos y los débitos fueron al cubo principal. Estas asignaciones y reglas estaban sujetas a cambios a lo largo del tiempo.

Imagine consultar 100.000 saldos de clientes sobre la marcha frente a las cambiantes reglas de negocios a lo largo del tiempo. Este es un caso sólido donde tener el valor derivado realmente tiene sentido. Mantuvimos un conjunto de algoritmos para "rebobinar" la cuenta y reconstruir el balance cronológicamente con fines de auditoría y verificación, pero no era nada que quisieras hacer para conjuntos grandes.

Answer 8

Todos aquí están en lo cierto. Depende. Pero puedes tener lo mejor de ambos mundos usando una vista. Parece que podría tener un sistema bastante pequeño, y calcular dinámicamente el saldo será lo más fácil de hacer. Para mantenerlo simple, definiría una vista única que tiene los datos de la cuenta que desea (calculados dinámicamente).

Si va a necesitar más rendimiento que eso, establecería un sistema basado en disparadores para actualizar el saldo a la tabla de la cuenta principal, luego actualizaría la vista entre bastidores para que no tenga que cambiar cualquier otro código Solo asegúrate de estar usando el modo de aislamiento de base de datos correcto para cualquier consulta, ¡o tendrás problemas! ;-)