Wenn niemand mehr sagen soll: „Das war ich nicht“
Du kennst das.
Ein Wert wurde geändert. Irgendwann. Von irgendwem.
Und keiner will’s gewesen sein.
Klassische Lösung: Trigger, Shadow Tables, Protokolle.
Komplex. Fehleranfällig. Manipulierbar.
Mit Ledger Tables bringt SQL Server eine Blockchain-ähnliche Funktion direkt ins System.
Ab SQL Server 2022 – für alle, die nachvollziehen müssen, was wann wie geändert wurde.
Was ist eine Ledger Table?
- Eine Tabelle mit eingebauter, unveränderbarer Historie
- Änderungen sind nachvollziehbar, aber nicht manipulierbar
- SQL Server berechnet kryptografische Hashes
- Unterstützt Prüfbarkeit über einen Verifikations-Hash
- Funktioniert ohne Blockchain-Know-how
Zwei Typen:
| Typ | Einsatz |
|---|---|
| Updatable Ledger | normale Tabelle mit Historie |
| Append-only | nur INSERT, kein UPDATE/DELETE |
Beispiel: Updatable Ledger Table erstellen
CREATE LEDGER TABLE dbo.Konto (
konto_id INT PRIMARY KEY,
inhaber NVARCHAR(100),
saldo DECIMAL(12,2)
)
WITH (SYSTEM_VERSIONING = ON);
Was passiert:
- Jede Änderung wird automatisch historisiert
- SQL Server erzeugt ein internes History-Table
- Zusätzlich: kryptografische Signatur jeder Änderung
Beispiel: Append-only Ledger Table
CREATE LEDGER TABLE dbo.Transaktionen (
transaktion_id INT PRIMARY KEY,
konto_id INT,
betrag DECIMAL(12,2),
ts DATETIME2 GENERATED ALWAYS AS ROW START
)
WITH (LEDGER = APPEND_ONLY);
Nur neue Datensätze erlaubt.
Ideal für Journal-Tabellen, Protokolle, Rechnungszeilen.
Historie abfragen
SELECT *
FROM sys.database_ledger_transactions;
SELECT *
FROM sys.database_ledger_blocks;
SELECT *
FROM sys.ledger_history_for_transaction_id(123456789);
So kannst Du sehen:
- Was wurde geändert?
- In welchem Block?
- Durch welche TX?
Verifikation: alles noch echt?
Du kannst jederzeit prüfen, ob Ledger-Historie verändert wurde.
EXEC sp_generate_database_ledger_digest;
Der Digest (SHA-256-Hash) kann exportiert werden – z. B. per API, Mail, SFTP.
Externe Stelle kann dann die Unverfälschtheit der Historie bestätigen.
Oder:
SELECT * FROM sys.database_ledger_digest_operations;
Hier steht, wann Digests erzeugt wurden.
Vorteile für KMU
| Vorteil | Beschreibung |
|---|---|
| Kein Trigger nötig | Historie ist nativ |
| Manipulationssicher | dank Hashkette und Blockstruktur |
| Audit-ready | inkl. Prüfbericht und Hash-Export |
| Minimaler Overhead | nur geringfügig langsamer als Standardtabellen |
| Einfach per T-SQL | keine externe Blockchain, kein Tooling |
Einschränkungen
- Kein ALTER TABLE ohne DROP/RECREATE
- Kein TRUNCATE
- Kein BCP oder BULK INSERT ohne Ledger-Unterstützung
- Keine direkte Manipulation der History
- Kein „Vergessen“ einzelner Datensätze (DSGVO = schwierig)
Mein Fazit
Ledger Tables sind kein Gimmick.
Sie sind ein ernstzunehmendes Feature, wenn Nachvollziehbarkeit zählt.
Gerade in sensiblen Prozessen – Finanzen, Compliance, QM – kann das den Unterschied machen.
Ohne dass Du dafür externe Systeme oder Blockchain-Plattformen einführen musst.
Wenn Du willst, bau ich Dir ein Ledger-Protokoll für sensible Tabellen auf.
Dann gibt’s keine Diskussion mehr, wer was wann geändert hat.
Keine Antworten