Warum Sie den Verlauf speichern sollten
Audits, Rückgängigmachen und Analysen vergangener Daten
Warum Sie den Verlauf speichern sollten ist eine kostenlose SQL Academy-Lektion auf CoddyKit. Dies ist Lektion 1 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des SQL Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der SQL Academy-Kurs umfasst insgesamt 4 Lektionen.
Das Problem beim Überschreiben
Jedes Mal, wenn Sie ein UPDATE oder DELETE ausführen, gehen die alten Daten unwiederbringlich verloren. Das klingt effizient, führt aber zu konkreten Problemen: Sie können Fragen wie Wie hoch war der Preis letzten Dienstag? oder Wer hat diesen Datensatz wann geändert? nicht beantworten.
Historie zu bewahren bedeutet, jede Version einer Zeile zu speichern, nicht nur die neueste. In dieser Lektion erfahren Sie, warum das wichtig ist und wie SQL Sie dabei unterstützt.
Drei Gründe, die Historie zu bewahren
Es gibt drei klassische Gründe, historische Daten in einer Datenbank zu bewahren:
1. Audit – nachweisen, dass eine Änderung stattgefunden hat, wer sie vorgenommen hat und wann.
2. Rückgängigmachen – einen Fehler zurücknehmen, ohne die gesamte Datenbank wiederherzustellen.
3. Analysen – Fragen zur Vergangenheit beantworten, Trends erkennen und Zeiträume vergleichen.
Eine gut durchdachte Historisierungsstrategie erfüllt alle drei Anforderungen, ohne zu viel Speicherplatz durch Duplikate zu verbrauchen.
Eine einfache Audit-Tabelle
Der einfachste Ansatz ist eine separate Audit-Tabelle, die jede Änderung protokolliert. Jede Zeile erfasst den alten Wert, den neuen Wert, die Person, die die Änderung vorgenommen hat, und den Zeitpunkt.
Nachfolgend sehen Sie eine Audit-Tabelle für eine products-Tabelle. Die Spalte operation speichert INSERT, UPDATE oder DELETE.
CREATE TABLE products_audit (
audit_id SERIAL PRIMARY KEY,
product_id INT NOT NULL,
operation VARCHAR(6) NOT NULL, -- INSERT / UPDATE / DELETE
old_price NUMERIC(10,2),
new_price NUMERIC(10,2),
changed_by TEXT NOT NULL,
changed_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);Die Audit-Tabelle befüllen
Sie können manuell in eine Audit-Tabelle schreiben. Am zuverlässigsten ist jedoch ein Datenbank-Trigger, der automatisch ausgelöst wird, sobald sich Daten ändern. So kann kein Anwendungscode das Protokoll umgehen.
Hier fügen wir direkt eine Audit-Zeile ein, um die Struktur zu veranschaulichen, bevor wir uns mit Triggern befassen.
INSERT INTO products_audit (product_id, operation, old_price, new_price, changed_by)
VALUES (42, 'UPDATE', 9.99, 12.49, 'alice');
SELECT * FROM products_audit ORDER BY changed_at DESC LIMIT 5;Den Audit-Trail lesen
Sobald sich Zeilen in der Audit-Tabelle angesammelt haben, können Sie sie abfragen, um Audit-Fragen zu beantworten. Die folgende Abfrage zeigt die vollständige Preishistorie für ein einzelnes Produkt, beginnend mit dem aktuellsten Eintrag.
SELECT
changed_at,
changed_by,
operation,
old_price,
new_price
FROM products_audit
WHERE product_id = 42
ORDER BY changed_at DESC;Gültigkeitsdaten: Historie der tatsächlichen Gültigkeit
Eine Audit-Tabelle erfasst, wann Sie die Änderung vorgenommen haben (Transaktionszeit). Manchmal müssen Sie zusätzlich nachverfolgen, wann etwas in der realen Welt gültig war – dies wird als Gültigkeitszeit bezeichnet.
Durch das Hinzufügen der Spalten valid_from und valid_to zur Haupttabelle entsteht eine Historie der Gültigkeitszeit, die manchmal als langsam veränderliche Dimension (SCD Type 2) bezeichnet wird.
CREATE TABLE employee_history (
id SERIAL PRIMARY KEY,
employee_id INT NOT NULL,
department TEXT NOT NULL,
salary NUMERIC(10,2) NOT NULL,
valid_from DATE NOT NULL,
valid_to DATE -- NULL means current record
);
-- Current record for employee 7
INSERT INTO employee_history (employee_id, department, salary, valid_from)
VALUES (7, 'Engineering', 85000, '2023-01-01');Einen langsam veränderlichen Datensatz aktualisieren
Wenn ein Mitarbeiter die Abteilung wechselt, aktualisieren Sie seine Zeile nicht mit UPDATE. Stattdessen schließen Sie die alte Zeile, indem Sie valid_to setzen, und fügen eine neue, noch offene Zeile ein. So bleibt die vollständige Historie erhalten.
-- Step 1: close the current record
UPDATE employee_history
SET valid_to = '2024-06-01'
WHERE employee_id = 7 AND valid_to IS NULL;
-- Step 2: insert the new record
INSERT INTO employee_history (employee_id, department, salary, valid_from)
VALUES (7, 'Product', 90000, '2024-06-01');
-- Verify history
SELECT department, salary, valid_from, valid_to
FROM employee_history
WHERE employee_id = 7
ORDER BY valid_from;Eine Abfrage zu einem bestimmten Zeitpunkt
Mit Spalten für die Gültigkeitszeit können Sie fragen, was an einem bestimmten Datum gültig war – eine Abfrage, die mit einem einfachen UPDATE-Modell nicht möglich wäre.
Die WHERE-Klausel prüft, ob das Zieldatum innerhalb des Gültigkeitszeitraums der Zeile liegt.
-- What department and salary did employee 7 have on 2023-09-15?
SELECT department, salary, valid_from, valid_to
FROM employee_history
WHERE employee_id = 7
AND valid_from <= '2023-09-15'
AND (valid_to > '2023-09-15' OR valid_to IS NULL);Systemversionierte temporale Tabellen
Moderne SQL-Datenbanken (PostgreSQL 16+, SQL Server, MySQL 8) unterstützen systemversionierte temporale Tabellen. Die Datenbank erfasst die Transaktionszeit automatisch in ausgeblendeten Spalten, und Sie können vergangene Zustände mit einer speziellen Syntax abfragen.
Beispiel für SQL Server – das Konzept ist in allen Engines gleich:
-- SQL Server / MariaDB style (illustrative)
CREATE TABLE orders (
order_id INT PRIMARY KEY,
status VARCHAR(20),
total NUMERIC(10,2),
SysStartTime DATETIME2 GENERATED ALWAYS AS ROW START,
SysEndTime DATETIME2 GENERATED ALWAYS AS ROW END,
PERIOD FOR SYSTEM_TIME (SysStartTime, SysEndTime)
) WITH (SYSTEM_VERSIONING = ON);
-- Query historical state
SELECT * FROM orders FOR SYSTEM_TIME AS OF '2024-01-15 12:00:00'
WHERE order_id = 100;Historie zum Rückgängigmachen verwenden
Historientabellen dienen nicht nur zum Lesen — Sie können sie auch verwenden, um Fehler rückgängig zu machen. Wenn ein Batch-Job 500 Preisdatensätze beschädigt hat, können Sie sie aus der Audit-Tabelle wiederherstellen, ohne auf ein Backup zugreifen zu müssen.
-- Undo all price changes made by the bad batch job at a specific time
UPDATE products p
SET price = a.old_price
FROM products_audit a
WHERE p.id = a.product_id
AND a.operation = 'UPDATE'
AND a.changed_by = 'batch_job'
AND a.changed_at BETWEEN '2024-03-10 02:00:00' AND '2024-03-10 02:05:00';
-- Confirm affected rows
SELECT COUNT(*) AS rows_restored FROM products_audit
WHERE changed_by = 'batch_job'
AND changed_at BETWEEN '2024-03-10 02:00:00' AND '2024-03-10 02:05:00';Analysen im Zeitverlauf
Historiedaten ermöglichen Zeitreihenanalysen. Sie können verfolgen, wie sich eine Kennzahl entwickelt hat, Monatswerte vergleichen oder Anomalien erkennen — und das alles, ohne ein separates Data Warehouse zu benötigen.
Diese Abfrage zeigt den durchschnittlichen Preis eines Produkts für jeden Kalendermonat anhand der Audit-Tabelle.
SELECT
DATE_TRUNC('month', changed_at) AS month,
ROUND(AVG(new_price), 2) AS avg_price
FROM products_audit
WHERE product_id = 42
AND operation IN ('INSERT', 'UPDATE')
GROUP BY 1
ORDER BY 1;Wissenscheck
Testen Sie Ihr Verständnis der Speicherung historischer Daten in SQL.
Zusammenfassung: Warum die Historie erhalten?
In dieser Lektion haben Sie gelernt, warum das Überschreiben von Daten riskant ist und wie SQL-Muster die Historie für Audits, das Rückgängigmachen und Analysen bewahren.
Wichtige Erkenntnisse:
- Audit-Tabellen protokollieren jedes INSERT, UPDATE und DELETE sowie, wer es wann ausgeführt hat.
- Gültigkeitszeit- (SCD-Typ-2-) Zeilen verwenden die Spalten
valid_from/valid_to, um Zeitverläufe in der realen Welt zu erfassen. - Stichtagsabfragen beantworten historische Fragen, indem sie nach diesen Datumsspalten filtern.
- Systemversionierte temporale Tabellen automatisieren die Erfassung der Transaktionszeit auf Datenbankebene.
- Historiedaten ermöglichen ein gezieltes Rückgängigmachen und umfangreiche Zeitreihenanalysen, ohne dass Backups benötigt werden.
Die Vergangenheit zu bewahren ist kein Overhead — sie ist die Grundlage für vertrauenswürdige und prüfbare Systeme.
Häufig gestellte Fragen
Ist die Lektion „Warum Sie den Verlauf speichern sollten“ kostenlos?
Ja — der vollständige Text von „Warum Sie den Verlauf speichern sollten“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des SQL Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der SQL Academy-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Warum Sie den Verlauf speichern sollten“?
Audits, Rückgängigmachen und Analysen vergangener Daten Du übst SQL Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um SQL Academy zu starten?
Keine Vorkenntnisse erforderlich. SQL Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 1 von 4.
Wie lange dauert die Lektion „Warum Sie den Verlauf speichern sollten“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser SQL Academy-Lektion Code schreiben und ausführen?
Ja. Jede SQL Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- Warum Sie den Verlauf speichern sollten
- Eventtabellen mit ausschließlichem Anhängen
- Temporale und versionierte Zeilen
- Zustand aus Events rekonstruieren