database - variable - La mejor forma de mantener el saldo de una cuenta de cliente
string visual basic (8)
¿Es mejor tener un campo en la base de datos que almacene el saldo de la cuenta del cliente o usar vistas y consultas para generar la información?
Creo que esto depende de muchos factores, con qué frecuencia accederá al saldo, qué tan complejo es volver a calcularlo cada vez que lo necesite. ¿Cuáles son los gastos generales de tener vistas, etc.
Puramente en la cara de la información que ha proporcionado, almacenaría el valor, ya que recalcularlo desde cero cada vez podría ser un problema.
Use las vistas y las consultas: le sorprenderá la velocidad con la que se ejecutará.
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.
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.
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.
Un proyecto en el que trabajé almacenaba el saldo actual en un campo y todas las transacciones en otra tabla, pero debido al nivel de importancia que tenía este proyecto en que los datos eran perfectos al 100% (o mejor) o al tiempo, también almacenó un hash de la balanza en otro campo y se comparó el hash 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 para enviarlo al departamento de atención al cliente. para la revisión.
"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 punto:
Trabajé en una aplicación de base de datos de crédito, donde el saldo se componía de muchas cosas diferentes y diferentes reglas comerciales a lo largo del tiempo. Por ejemplo, el "saldo" era en realidad una suma de saldos diferentes de diferentes categorías, como Principal, Honorarios, etc.
A medida que se contabilizaban las transacciones, se asignaban a diferentes segmentos 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 balances 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.
Todos aquí están en lo correcto. 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 detrás de las escenas para que no tenga que cambiar ningún 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! ;-)