Schreiben eines einfachen Bankschemas: Wie soll ich meine Guthaben mit dem Transaktionsverlauf synchronisieren?

Ich schreibe das Schema für eine einfache Bankdatenbank. Hier sind die grundlegenden Spezifikationen:

• In der Datenbank werden Transaktionen für einen Benutzer und eine Währung gespeichert.
• Jeder Benutzer verfügt über einen Kontostand pro Währung. Jeder Kontostand ist also einfach die Summe aller Transaktionen mit einem bestimmten Benutzer und einer bestimmten Währung.
• Ein Saldo kann nicht negativ sein.

Die Bankanwendung kommuniziert mit ihrer Datenbank ausschließlich über gespeicherte Prozeduren.

Ich erwarte, dass diese Datenbank Hunderttausende neuer Transaktionen pro Tag akzeptiert und Abfragen in einer höheren Größenordnung ausgleicht. Um die Salden sehr schnell aufzufüllen, muss ich sie vorab aggregieren. Gleichzeitig muss ich garantieren, dass ein Kontostand niemals seiner Transaktionshistorie widerspricht.

Meine Optionen sind:

1. Haben Sie eine separate balancesTabelle und führen Sie einen der folgenden Schritte aus:

   1. Wenden Sie Transaktionen auf die Tabellen transactionsund an balances. Verwenden Sie TRANSACTIONLogik in meiner gespeicherten Prozedurebene, um sicherzustellen, dass Salden und Transaktionen immer synchron sind. (Unterstützt von Jack .)

   2. Wenden Sie Transaktionen auf die transactionsTabelle an und haben Sie einen Auslöser, der die balancesTabelle für mich mit dem Transaktionsbetrag aktualisiert .

   3. Wenden Sie Transaktionen auf die balancesTabelle an und haben Sie einen Auslöser, der transactionsmir einen neuen Eintrag in der Tabelle mit dem Transaktionsbetrag hinzufügt .

   Ich muss mich auf sicherheitsbasierte Ansätze verlassen, um sicherzustellen, dass keine Änderungen außerhalb der gespeicherten Prozeduren vorgenommen werden können. Andernfalls könnte beispielsweise ein Prozess eine Transaktion direkt in die transactionsTabelle einfügen, und 1.3der betreffende Saldo wäre nach dem Schema nicht synchron.

2. Haben Sie eine balancesindizierte Ansicht , die die Transaktionen entsprechend aggregiert. Die Speicher-Engine garantiert, dass die Salden mit ihren Transaktionen synchron bleiben, sodass ich mich nicht auf sicherheitsbasierte Ansätze verlassen muss, um dies zu gewährleisten. Andererseits kann ich nicht erzwingen, dass Salden nicht mehr negativ sind, da Ansichten - auch indizierte Ansichten - keine CHECKEinschränkungen aufweisen können. (Unterstützt von Denny .)

3. Haben Sie nur eine transactionsTabelle, aber mit einer zusätzlichen Spalte, um den Saldo direkt nach der Ausführung dieser Transaktion zu speichern. Somit enthält der letzte Transaktionsdatensatz für einen Benutzer und eine Währung auch den aktuellen Kontostand. (Vorgeschlagen von Andrew ; von Garik vorgeschlagene Variante .)

Als ich dieses Problem zum ersten Mal ansprach, las ich diese beiden Diskussionen und entschied mich für eine Option 2. Als Referenz können Sie hier eine Bare-Bones-Implementierung sehen .

• Haben Sie eine solche Datenbank mit einem hohen Lastprofil entworfen oder verwaltet? Was war Ihre Lösung für dieses Problem?

• Glaubst du, ich habe die richtige Wahl getroffen? Was sollte ich beachten?

  Ich weiß beispielsweise, dass Schemaänderungen an der transactionsTabelle eine Neuerstellung der balancesAnsicht erfordern . Selbst wenn ich Transaktionen archiviere, um die Datenbank klein zu halten (z. B. indem ich sie an einen anderen Ort verschiebe und durch Zusammenfassungstransaktionen ersetze), bedeutet die Neuerstellung der Ansicht aus zig Millionen Transaktionen mit jeder Schemaaktualisierung wahrscheinlich eine erheblich längere Ausfallzeit pro Bereitstellung.

• Wie kann ich garantieren, dass kein Saldo negativ ist, wenn die indizierte Ansicht der richtige Weg ist?

Transaktionen archivieren:

Lassen Sie mich ein wenig auf die Archivierungstransaktionen und die "Zusammenfassungstransaktionen" eingehen, die ich oben erwähnt habe. Erstens ist in einem Hochlastsystem wie diesem eine regelmäßige Archivierung erforderlich. Ich möchte die Konsistenz zwischen Salden und ihren Transaktionsverläufen gewährleisten und gleichzeitig alte Transaktionen an einen anderen Ort verschieben. Dazu ersetze ich jeden Stapel archivierter Transaktionen durch eine Zusammenfassung ihrer Beträge pro Benutzer und Währung.

So zum Beispiel diese Liste von Transaktionen:

user_id    currency_id      amount    is_summary
------------------------------------------------
      3              1       10.60             0
      3              1      -55.00             0
      3              1      -12.12             0

wird archiviert und ersetzt durch:

user_id    currency_id      amount    is_summary
------------------------------------------------
      3              1      -56.52             1

Auf diese Weise behält ein Saldo mit archivierten Transaktionen eine vollständige und konsistente Transaktionshistorie bei.

Ich bin mit der Buchhaltung nicht vertraut, habe jedoch einige ähnliche Probleme in Umgebungen mit Bestandsaufnahmen gelöst. Ich speichere laufende Summen in derselben Zeile wie die Transaktion. Ich verwende Einschränkungen, damit meine Daten auch bei hoher Parallelität niemals falsch sind. Ich habe damals im Jahr 2009 folgende Lösung geschrieben :

Das Berechnen von laufenden Summen ist notorisch langsam, egal ob Sie sie mit einem Cursor oder mit einer Dreiecksverknüpfung ausführen. Es ist sehr verlockend zu denormalisieren, laufende Summen in einer Spalte zu speichern, besonders wenn Sie diese häufig auswählen. Beim Denormalisieren müssen Sie jedoch wie gewohnt die Integrität Ihrer denormalisierten Daten gewährleisten. Glücklicherweise können Sie die Integrität von laufenden Summen mit Einschränkungen garantieren. Solange alle Ihre Einschränkungen vertrauenswürdig sind, sind alle laufenden Summen korrekt. Auch auf diese Weise können Sie auf einfache Weise sicherstellen, dass der aktuelle Kontostand (laufende Summen) niemals negativ ist - die Durchsetzung durch andere Methoden kann auch sehr langsam sein. Das folgende Skript demonstriert die Technik.

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)
  )
);

-- 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

Kunden ein Guthaben von weniger als 0 zu verweigern, ist eine Geschäftsregel (die sich schnell ändern würde, da Banken mit Gebühren für Überziehungskredite den größten Teil ihres Geldes verdienen). Sie möchten dies in der Anwendungsverarbeitung behandeln, wenn Zeilen in den Transaktionsverlauf eingefügt werden. Zumal einige Kunden möglicherweise einen Überziehungsschutz haben und andere Gebühren verlangen und andere die Eingabe negativer Beträge nicht zulassen.

Soweit gefällt mir, wohin Sie gehen, aber wenn dies für ein tatsächliches Projekt (nicht für die Schule) ist, müssen verdammt viele Gedanken in Geschäftsregeln usw. gesteckt werden. Sobald Sie ein Bankensystem eingerichtet haben und beim Laufen gibt es nicht viel Raum für eine Neugestaltung, da es sehr spezifische Gesetze gibt, wonach Menschen Zugang zu ihrem Geld haben.

Ein etwas anderer Ansatz (ähnlich wie bei Ihrer zweiten Option) besteht darin, nur die Transaktionstabelle mit einer Definition von:

CREATE TABLE Transaction (
      UserID              INT
    , CurrencyID          INT 
    , TransactionDate     DATETIME  
    , OpeningBalance      MONEY
    , TransactionAmount   MONEY
);

Möglicherweise möchten Sie auch eine Transaktions-ID / Bestellung, damit Sie zwei Transaktionen mit demselben Datum bearbeiten und Ihre Abfrage verbessern können.

Um das aktuelle Guthaben zu erhalten, müssen Sie lediglich den letzten Datensatz abrufen.

Methoden, um den letzten Datensatz abzurufen :

/* For a single User/Currency */
Select TOP 1 *
FROM dbo.Transaction
WHERE UserID = 3 and CurrencyID = 1
ORDER By TransactionDate desc

/* For multiple records ie: to put into a view (which you might want to index) */
SELECT
    C.*
FROM
    (SELECT 
        *, 
        ROW_NUMBER() OVER (
           PARTITION BY UserID, CurrencyID 
           ORDER BY TransactionDate DESC
        ) AS rnBalance 
    FROM Transaction) C
WHERE
    C.rnBalance = 1
ORDER BY
    C.UserID, C.CurrencyID

Nachteile:

• Wenn Sie eine Transaktion außerhalb der angegebenen Reihenfolge einfügen (z. B. um ein Problem zu beheben oder einen falschen Startsaldo), müssen Sie möglicherweise Aktualisierungen für alle nachfolgenden Transaktionen kaskadieren.

• Transaktionen für den Benutzer / die Währung müssten serialisiert werden, um einen genauen Saldo zu erhalten.

  -- Example of getting the current balance and locking the 
  -- last record for that User/Currency.
  -- This lock will be freed after the Stored Procedure completes.
  SELECT TOP 1 @OldBalance = OpeningBalance + TransactionAmount  
  FROM dbo.Transaction with (rowlock, xlock)   
  WHERE UserID = 3 and CurrencyID = 1  
  ORDER By TransactionDate DESC;
  

Vorteile:

• Sie müssen nicht mehr zwei separate Tabellen pflegen ...
• Sie können den Saldo auf einfache Weise validieren, und wenn der Saldo nicht mehr synchron ist, können Sie genau feststellen, wann er aus dem Gleichgewicht geraten ist, da der Transaktionsverlauf sich selbst dokumentiert.

Bearbeiten: Einige Beispielabfragen zum Abrufen des aktuellen Guthabens und zum Hervorheben von Betrug (Danke @Jack Douglas)

Nachdem ich diese beiden Diskussionen gelesen hatte, entschied ich mich für Option 2

Nachdem Sie diese Diskussionen ebenfalls gelesen haben, bin ich mir nicht sicher, warum Sie sich für die DRI- Lösung entschieden haben, anstatt der sinnvollsten der anderen Optionen, die Sie skizzieren:

Wenden Sie Transaktionen sowohl auf die Transaktions- als auch auf die Salden-Tabelle an. Verwenden Sie die TRANSACTION-Logik in meiner Schicht für gespeicherte Prozeduren, um sicherzustellen, dass Salden und Transaktionen immer synchron sind.

Diese Art von Lösung bietet enorme praktische Vorteile, wenn Sie den Luxus haben, den gesamten Zugriff auf die Daten über Ihre Transaktions-API einzuschränken . Sie verlieren den sehr wichtigen Vorteil von DRI: Die Integrität wird durch die Datenbank garantiert. In jedem Modell mit ausreichender Komplexität gibt es jedoch einige Geschäftsregeln, die von DRI nicht erzwungen werden können .

Ich würde empfehlen, DRI zu verwenden, wenn dies möglich ist, um Geschäftsregeln durchzusetzen, ohne Ihr Modell zu stark zu verbiegen:

Auch wenn ich Transaktionen archiviere (z. B. indem ich sie an einen anderen Ort verschiebe und durch zusammenfassende Transaktionen ersetze)

Sobald Sie erwägen, Ihr Modell auf diese Weise zu verschmutzen, bewegen Sie sich vermutlich in einem Bereich, in dem der Nutzen von DRI durch die von Ihnen eingeführten Schwierigkeiten überwiegt. Stellen Sie sich zum Beispiel vor, dass ein Fehler in Ihrem Archivierungsprozess theoretisch dazu führen könnte, dass Ihre goldene Regel (bei der der Saldo immer gleich der Summe der Transaktionen ist) stillschweigend mit einer DRI-Lösung bricht .

Hier ist eine Zusammenfassung der Vorteile des Transaktionsansatzes, wie ich sie sehe:

• Wir sollten dies sowieso tun, wenn es überhaupt möglich ist. Unabhängig davon, welche Lösung Sie für dieses spezielle Problem wählen, bietet es Ihnen mehr Flexibilität beim Entwurf und Kontrolle über Ihre Daten. Jeder Zugriff wird dann in Bezug auf die Geschäftslogik "transaktional" und nicht nur in Bezug auf die Datenbanklogik.
• Sie können Ihr Modell ordentlich halten
• Sie können eine viel breitere Palette und Komplexität von Geschäftsregeln "erzwingen" (wobei zu beachten ist, dass das Konzept "erzwingen" weniger wichtig ist als bei DRI).
• Sie können DRI weiterhin verwenden, wo immer dies sinnvoll ist, um dem Modell eine stabilere zugrunde liegende Integrität zu verleihen. Dies kann als Überprüfung Ihrer Transaktionslogik dienen
• Die meisten Leistungsprobleme, die Sie stören, werden verschwinden
• Das Einführen neuer Anforderungen kann viel einfacher sein - zum Beispiel: Komplexe Regeln für umstrittene Transaktionen können Sie von einem reinen DRI-Ansatz abhalten, was eine Menge unnötigen Aufwand bedeutet
• Das Partitionieren oder Archivieren von historischen Daten ist weniger riskant und schmerzhaft

--bearbeiten

Um die Archivierung zu ermöglichen, ohne die Komplexität oder das Risiko zu erhöhen, können Sie Zusammenfassungstabellen in einer separaten Zusammenfassungstabelle speichern, die fortlaufend generiert wird (Ausleihe von @Andrew und @Garik).

Zum Beispiel, wenn die Zusammenfassungen monatlich sind:

• Bei jeder Transaktion (über Ihre API) wird eine entsprechende Aktualisierung durchgeführt oder in die Übersichtstabelle eingefügt
• Die Übersichtstabelle wird nie archiviert, aber Archivierungstransaktionen werden so einfach wie ein Löschen (oder Löschen einer Partition?)
• Jede Zeile in der Übersichtstabelle enthält "Anfangsbestand" und "Betrag".
• Prüfbeschränkungen wie 'Anfangsbestand' + 'Betrag'> 0 und 'Anfangsbestand'> 0 können auf die Übersichtstabelle angewendet werden
• Zusammenfassungszeilen können in einem monatlichen Stapel eingefügt werden, um das Sperren der letzten Zusammenfassungszeile zu vereinfachen (es würde immer eine Zeile für den aktuellen Monat geben).

Nick.

Die Hauptidee besteht darin, Saldo und Transaktionsdatensätze in derselben Tabelle zu speichern. Es ist historisch passiert, dachte ich. In diesem Fall können wir das Gleichgewicht nur durch Auffinden des letzten Zusammenfassungsdatensatzes erreichen.

 id   user_id    currency_id      amount    is_summary (or record_type)
----------------------------------------------------
  1       3              1       10.60             0
  2       3              1       10.60             1    -- summary after transaction 1
  3       3              1      -55.00             0
  4       3              1      -44.40             1    -- summary after transactions 1 and 3
  5       3              1      -12.12             0
  6       3              1      -56.52             1    -- summary after transactions 1, 3 and 5 

Eine bessere Variante besteht darin, die Anzahl der Zusammenfassungsdatensätze zu verringern. Wir können einen Saldodatensatz am Ende (und / oder Anfang) des Tages haben. Wie Sie wissen, muss jede Bank operational daysie öffnen und schließen, um einige Zusammenfassungsoperationen für diesen Tag durchzuführen. Es ermöglicht uns die einfache Berechnung von Zinsen, indem wir den täglichen Saldodatensatz verwenden, zum Beispiel:

user_id    currency_id      amount    is_summary    oper_date
--------------------------------------------------------------
      3              1       10.60             0    01/01/2011 
      3              1      -55.00             0    01/01/2011
      3              1      -44.40             1    01/01/2011 -- summary at the end of day (01/01/2011)
      3              1      -12.12             0    01/02/2011
      3              1      -56.52             1    01/02/2011 -- summary at the end of day (01/02/2011)

Glück.

Je nach Ihren Anforderungen erscheint Option 1 am besten. Obwohl ich mein Design haben würde, um nur Einfügungen in die Transaktionstabelle zuzulassen. Und haben Sie den Auslöser für die Transaktionstabelle, um die Echtzeit-Balance-Tabelle zu aktualisieren. Sie können Datenbankberechtigungen verwenden, um den Zugriff auf diese Tabellen zu steuern.

Bei diesem Ansatz ist garantiert, dass das Echtzeitguthaben mit der Transaktionstabelle synchron ist. Dabei spielt es keine Rolle, ob gespeicherte Prozeduren oder psql oder jdbc verwendet werden. Sie können Ihren negativen Kontostand bei Bedarf überprüfen lassen. Leistung wird kein Problem sein. Um die Echtzeitbilanz zu erhalten, handelt es sich um eine Einzelabfrage.

Die Archivierung hat keinen Einfluss auf diesen Ansatz. Sie können eine wöchentliche, monatliche und jährliche Übersichtstabelle erstellen, auch wenn dies für Berichte erforderlich ist.

In Oracle können Sie dazu nur die Transaktionstabelle mit einer schnell aktualisierbaren Materialized View verwenden, die die Aggregation zur Bildung des Saldos vornimmt. Sie definieren den Auslöser für die materialisierte Ansicht. Wenn die materialisierte Ansicht mit 'ON COMMIT' definiert ist, wird das Hinzufügen / Ändern von Daten in den Basistabellen effektiv verhindert. Der Trigger erkennt die [in] gültigen Daten und löst eine Ausnahme aus, bei der die Transaktion zurückgesetzt wird. Ein schönes Beispiel ist hier http://www.sqlsnippets.com/en/topic-12896.html

Ich kenne sqlserver nicht, aber vielleicht gibt es eine ähnliche Option?