Laufender Saldo und Datenbank-Normalisierungsparadigma

Question

Vielleicht bin ich nicht gut im Googeln, aber ich suche nach einem Satz goldener Regeln und Empfehlungen zur Gestaltung von Datenbanken im Zusammenhang mit Abrechnungen.

Angenommen, ich habe eine SQL-Tabelle mit Transaktionen

transactions(id int, credit float, debit float, billable_account_id int)

Basierend auf dem Prinzip der Datenbanknormalisierung verwerfe ich die Idee, den vorberechneten aktuellen Saldo für jede *billable_account_id* in derselben Tabelle oder an anderer Stelle unabhängig von der Größe der Transaktionstabelle zu speichern und zu aktualisieren.

Ich verwende Postgres, falls das eine Rolle spielt (obwohl das Thema allgemein ist), und ich bin überhaupt kein SQL-Ninja, versuche aber pedantisch zu sein in der Gestaltung.

Fragen:

1. Habe ich Recht, diesen Ansatz zu verfolgen?
2. Wenn ja, welche Methoden würden Sie vorschlagen, um eine solche Tabelle zu pflegen und Abfragen zum Abrufen von Gesamtsummen zu erstellen?

Alle Verweise sind sehr willkommen!

Answer 1

Sie können analytische Funktionen verwenden, um in den meisten Datenbanken eine laufende Gesamtsumme zu generieren. In Oracle sieht das etwa so aus

SELECT billable_account_id,
       SUM( (CASE WHEN credit IS NOT NULL THEN credit
                  WHEN debit IS NOT NULL THEN -1 * debit
                  ELSE 0 
                  END) ) OVER (PARTITION BY billable_account_id
                                   ORDER BY transaction_date ) running_total
  FROM transactions

Wenn Sie kein TRANSACTION_DATE haben, könnten Sie ID verwenden, vorausgesetzt, dass Sie garantieren können, dass die generierten IDs monoton steigen.

Allerdings werden Sie aus Leistungsgründen wahrscheinlich die dritte Normalform für OLAP/DSS-Typ-Berichte biegen, wenn nicht sogar brechen wollen, da die Leute sehr häufig Berichte über Summen erstellen wollen und einige Konten wahrscheinlich eine große Anzahl von Transaktionen haben. Sie könnten beispielsweise eine separate Tabelle erstellen, die für jedes BILLABLE_ACCOUNT_ID zum Monatsende ein Endguthaben hat, und dann die analytische Funktion verwenden, um die Transaktionen des laufenden Monats zum Endguthaben des letzten Monats hinzuzufügen. In Oracle könnten Sie eine materialisierte Ansicht erstellen, die automatisch die laufende Gesamtsumme pflegt.