¿Está bien mantener un valor que se actualiza en una tabla?

Estamos desarrollando una plataforma para tarjetas prepagas, que básicamente contiene datos sobre tarjetas y su saldo, pagos, etc.

Hasta ahora teníamos una entidad de Tarjeta que tiene una colección de entidad de Cuenta, y cada Cuenta tiene un Monto, que se actualiza en cada Depósito / Retiro.

Hay un debate ahora en el equipo; alguien nos ha dicho que esto rompe las 12 Reglas de Codd y que actualizar su valor en cada pago es un problema.

¿Es esto realmente un problema?

Si es así, ¿cómo podemos solucionar esto?

Sí, eso no está normalizado, pero en ocasiones los diseños no normalizados ganan por razones de rendimiento.

Sin embargo, probablemente lo abordaría de manera un poco diferente, por razones de seguridad. (Descargo de responsabilidad: actualmente no, ni he trabajado en el sector financiero. Solo estoy lanzando esto por ahí).

Tenga una tabla para los saldos publicados en las tarjetas. Esto tendría una fila insertada para cada cuenta, indicando el saldo registrado al cierre de cada período (día, semana, mes o lo que sea apropiado). Indice esta tabla por número de cuenta y fecha.

Use otra tabla para mantener las transacciones pendientes, que se insertan sobre la marcha. Al cierre de cada período, ejecute una rutina que agregue las transacciones no publicadas al último saldo de cierre de la cuenta para calcular el nuevo saldo. Marque las transacciones pendientes como publicadas, o mire las fechas para determinar qué está pendiente.

De esta manera, tiene un medio para calcular el saldo de la tarjeta a pedido, sin tener que resumir todo el historial de la cuenta, y al poner el recálculo del saldo en una rutina de contabilización dedicada, puede asegurarse de que la seguridad de la transacción de este recálculo se limite a un solo lugar (y también limitan la seguridad en la tabla de balance para que solo la rutina de contabilización pueda escribirle).

Luego, conserve la mayor cantidad de datos históricos que requiera la auditoría, el servicio al cliente y los requisitos de rendimiento.

Por otro lado, hay un problema que encontramos con frecuencia en el software de contabilidad. Parafraseado:

¿ Realmente necesito agregar diez años de datos para averiguar cuánto dinero hay en la cuenta corriente?

La respuesta, por supuesto, es no, no lo haces. Hay algunos enfoques aquí. Uno está almacenando el valor calculado. No recomiendo este enfoque porque los errores de software que causan valores incorrectos son muy difíciles de rastrear, por lo que evitaría este enfoque.

Una mejor manera de hacerlo es lo que yo llamo el enfoque agregado de registro de instantáneas. En este enfoque, nuestros pagos y usos son insertos y nunca actualizamos estos valores. Periódicamente agregamos los datos durante un período de tiempo e insertamos un registro de instantánea calculado que representa los datos en el momento en que la instantánea se hizo válida (generalmente un período de tiempo antes del presente).

Ahora, esto no rompe las reglas de Codd porque con el tiempo las instantáneas pueden ser menos que perfectamente dependientes de los datos de pago / uso insertados. Si tenemos instantáneas de trabajo, podemos decidir purgar datos de 10 años sin afectar nuestra capacidad de calcular los saldos actuales bajo demanda.

Por razones de rendimiento, en la mayoría de los casos debemos almacenar el saldo actual; de lo contrario, calcularlo sobre la marcha puede llegar a ser extremadamente lento.

Almacenamos totales acumulados precalculados en nuestro sistema. Para garantizar que los números sean siempre correctos, utilizamos restricciones. La siguiente solución ha sido copiada de mi blog. Describe un inventario, que es esencialmente el mismo problema:

Calcular los totales acumulados es notoriamente lento, ya sea que lo haga con un cursor o con una unión triangular. Es muy tentador desnormalizar, almacenar totales acumulados en una columna, especialmente si lo selecciona con frecuencia. Sin embargo, como es habitual cuando se desnormaliza, debe garantizar la integridad de sus datos desnormalizados. Afortunadamente, puede garantizar la integridad de los totales acumulados con restricciones: siempre y cuando todas sus restricciones sean confiables, todos sus totales acumulados son correctos. También de esta manera puede asegurarse fácilmente de que el saldo actual (totales acumulados) nunca sea negativo: la aplicación por otros métodos también puede ser muy lenta. El siguiente script demuestra la técnica.

CREATE TABLE Data.Inventory(InventoryID INT NOT NULL IDENTITY,
  ItemID INT NOT NULL,
  ChangeDate DATETIME NOT NULL,
  ChangeQty INT NOT NULL,
  TotalQty INT NOT NULL,
  PreviousChangeDate DATETIME NULL,
  PreviousTotalQty INT NULL,
  CONSTRAINT PK_Inventory PRIMARY KEY(ItemID, ChangeDate),
  CONSTRAINT UNQ_Inventory UNIQUE(ItemID, ChangeDate, TotalQty),
  CONSTRAINT UNQ_Inventory_Previous_Columns UNIQUE(ItemID, PreviousChangeDate, PreviousTotalQty),
  CONSTRAINT FK_Inventory_Self FOREIGN KEY(ItemID, PreviousChangeDate, PreviousTotalQty)
    REFERENCES Data.Inventory(ItemID, ChangeDate, TotalQty),
  CONSTRAINT CHK_Inventory_Valid_TotalQty CHECK(TotalQty >= 0 AND (TotalQty = COALESCE(PreviousTotalQty, 0) + ChangeQty)),
  CONSTRAINT CHK_Inventory_Valid_Dates_Sequence CHECK(PreviousChangeDate < ChangeDate),
  CONSTRAINT CHK_Inventory_Valid_Previous_Columns CHECK((PreviousChangeDate IS NULL AND PreviousTotalQty IS NULL)
            OR (PreviousChangeDate IS NOT NULL AND PreviousTotalQty IS NOT NULL))
);
GO
-- beginning of inventory for item 1
INSERT INTO Data.Inventory(ItemID,
  ChangeDate,
  ChangeQty,
  TotalQty,
  PreviousChangeDate,
  PreviousTotalQty)
VALUES(1, '20090101', 10, 10, NULL, NULL);
-- cannot begin the inventory for the second time for the same item 1
INSERT INTO Data.Inventory(ItemID,
  ChangeDate,
  ChangeQty,
  TotalQty,
  PreviousChangeDate,
  PreviousTotalQty)
VALUES(1, '20090102', 10, 10, NULL, NULL);

Msg 2627, Level 14, State 1, Line 10
Violation of UNIQUE KEY constraint 'UNQ_Inventory_Previous_Columns'. Cannot insert duplicate key in object 'Data.Inventory'.
The statement has been terminated.

-- add more
DECLARE @ChangeQty INT;
SET @ChangeQty = 5;
INSERT INTO Data.Inventory(ItemID,
  ChangeDate,
  ChangeQty,
  TotalQty,
  PreviousChangeDate,
  PreviousTotalQty)
SELECT TOP 1 ItemID, '20090103', @ChangeQty, TotalQty + @ChangeQty, ChangeDate, TotalQty
  FROM Data.Inventory
  WHERE ItemID = 1
  ORDER BY ChangeDate DESC;

SET @ChangeQty = 3;
INSERT INTO Data.Inventory(ItemID,
  ChangeDate,
  ChangeQty,
  TotalQty,
  PreviousChangeDate,
  PreviousTotalQty)
SELECT TOP 1 ItemID, '20090104', @ChangeQty, TotalQty + @ChangeQty, ChangeDate, TotalQty
  FROM Data.Inventory
  WHERE ItemID = 1
  ORDER BY ChangeDate DESC;

SET @ChangeQty = -4;
INSERT INTO Data.Inventory(ItemID,
  ChangeDate,
  ChangeQty,
  TotalQty,
  PreviousChangeDate,
  PreviousTotalQty)
SELECT TOP 1 ItemID, '20090105', @ChangeQty, TotalQty + @ChangeQty, ChangeDate, TotalQty
  FROM Data.Inventory
  WHERE ItemID = 1
  ORDER BY ChangeDate DESC;

-- try to violate chronological order

SET @ChangeQty = 5;
INSERT INTO Data.Inventory(ItemID,
  ChangeDate,
  ChangeQty,
  TotalQty,
  PreviousChangeDate,
  PreviousTotalQty)
SELECT TOP 1 ItemID, '20081231', @ChangeQty, TotalQty + @ChangeQty, ChangeDate, TotalQty
  FROM Data.Inventory
  WHERE ItemID = 1
  ORDER BY ChangeDate DESC;

Msg 547, Level 16, State 0, Line 4
The INSERT statement conflicted with the CHECK constraint "CHK_Inventory_Valid_Dates_Sequence". The conflict occurred in database "Test", table "Data.Inventory".
The statement has been terminated.


SELECT ChangeDate,
  ChangeQty,
  TotalQty,
  PreviousChangeDate,
  PreviousTotalQty
FROM Data.Inventory ORDER BY ChangeDate;

ChangeDate              ChangeQty   TotalQty    PreviousChangeDate      PreviousTotalQty
----------------------- ----------- ----------- ----------------------- -----
2009-01-01 00:00:00.000 10          10          NULL                    NULL
2009-01-03 00:00:00.000 5           15          2009-01-01 00:00:00.000 10
2009-01-04 00:00:00.000 3           18          2009-01-03 00:00:00.000 15
2009-01-05 00:00:00.000 -4          14          2009-01-04 00:00:00.000 18


-- try to change a single row, all updates must fail
UPDATE Data.Inventory SET ChangeQty = ChangeQty + 2 WHERE InventoryID = 3;
UPDATE Data.Inventory SET TotalQty = TotalQty + 2 WHERE InventoryID = 3;
-- try to delete not the last row, all deletes must fail
DELETE FROM Data.Inventory WHERE InventoryID = 1;
DELETE FROM Data.Inventory WHERE InventoryID = 3;

-- the right way to update

DECLARE @IncreaseQty INT;
SET @IncreaseQty = 2;
UPDATE Data.Inventory SET ChangeQty = ChangeQty + CASE WHEN ItemID = 1 AND ChangeDate = '20090103' THEN @IncreaseQty ELSE 0 END,
  TotalQty = TotalQty + @IncreaseQty,
  PreviousTotalQty = PreviousTotalQty + CASE WHEN ItemID = 1 AND ChangeDate = '20090103' THEN 0 ELSE @IncreaseQty END
WHERE ItemID = 1 AND ChangeDate >= '20090103';

SELECT ChangeDate,
  ChangeQty,
  TotalQty,
  PreviousChangeDate,
  PreviousTotalQty
FROM Data.Inventory ORDER BY ChangeDate;

ChangeDate              ChangeQty   TotalQty    PreviousChangeDate      PreviousTotalQty
----------------------- ----------- ----------- ----------------------- ----------------
2009-01-01 00:00:00.000 10          10          NULL                    NULL
2009-01-03 00:00:00.000 7           17          2009-01-01 00:00:00.000 10
2009-01-04 00:00:00.000 3           20          2009-01-03 00:00:00.000 17
2009-01-05 00:00:00.000 -4          16          2009-01-04 00:00:00.000 20

Esta es una muy buena pregunta.

Suponiendo que tiene una tabla de transacciones que almacena cada débito / crédito, su diseño no tiene nada de malo. De hecho, he trabajado con sistemas de telecomunicaciones prepagos que han funcionado exactamente de esta manera.

Lo principal que debe hacer es asegurarse de que está haciendo una parte SELECT ... FOR UPDATEdel saldo mientras realiza INSERTel débito / crédito. Esto garantizará el saldo correcto si algo sale mal (porque la transacción completa se revertirá).

Como otros han señalado, necesitará una instantánea de los saldos en períodos de tiempo específicos para verificar que todas las transacciones en un período determinado sumen los saldos de inicio / fin del período correctamente. Escriba un trabajo por lotes que se ejecute a medianoche al final del período (mes / semana / día) para hacer esto.

El saldo es una cantidad calculada basada en ciertas reglas comerciales, por lo que sí, no desea mantener el saldo sino calcularlo a partir de las transacciones en la tarjeta y, por lo tanto, de la cuenta.

Desea realizar un seguimiento de todas las transacciones en la tarjeta para auditoría e informes de estado de cuenta, e incluso datos de diferentes sistemas más adelante.

En pocas palabras: calcule cualquier valor que deba calcularse cuando lo necesite