Wenn Du Daten wegwirfst, wirfst Du Wissen weg

Viele Systeme speichern nur den aktuellen Stand. Änderungen? Überschrieben. Gelöscht. Vergessen.

Und dann fragt der Chef:
„Was stand da eigentlich vor sechs Monaten?“
Tja.

Wenn Du kein Archiv hast, kannst Du nichts beantworten.

Warum Archivierung wichtig ist

• Nachvollziehbarkeit bei Streitfällen
• Historie für Analysen (Trends, Entwicklung)
• Beweissicherung (z. B. bei Verträgen)
• Entlastung des Produktivsystems
• Dokumentation von Zustandsänderungen

Strategien für ein Datenarchiv

• Historische Tabelle per Trigger füllen
• Periodisches Auslagern (z. B. monatlich)
• Temporale Tabellen (ab SQL Server 2016)
• Change Data Capture (CDC) oder eigene Änderungslogik
• Vollständige Snapshots bei bestimmten Events

Beispiel 1: Trigger-Archiv für Änderungen

CREATE TABLE Kunden_Archiv (
    ArchivID INT IDENTITY(1,1) PRIMARY KEY,
    KundenID INT,
    Name NVARCHAR(100),
    Adresse NVARCHAR(200),
    Änderungsdatum DATETIME DEFAULT GETDATE(),
    Aktion CHAR(1) -- I = Insert, U = Update, D = Delete
);

CREATE TRIGGER trg_Kunden_Archiv
ON Kunden
AFTER INSERT, UPDATE, DELETE
AS
BEGIN
    SET NOCOUNT ON;

    -- Insert
    INSERT INTO Kunden_Archiv (KundenID, Name, Adresse, Aktion)
    SELECT KundenID, Name, Adresse, 'I'
    FROM inserted
    WHERE NOT EXISTS (SELECT * FROM deleted WHERE deleted.KundenID = inserted.KundenID);

    -- Update
    INSERT INTO Kunden_Archiv (KundenID, Name, Adresse, Aktion)
    SELECT KundenID, Name, Adresse, 'U'
    FROM inserted
    INNER JOIN deleted ON inserted.KundenID = deleted.KundenID;

    -- Delete
    INSERT INTO Kunden_Archiv (KundenID, Name, Adresse, Aktion)
    SELECT KundenID, Name, Adresse, 'D'
    FROM deleted;
END;

Du sicherst jede Änderung mit. Minimalistisch. Robust. Für kleine Tabellen reicht das.

Beispiel 2: Temporale Tabellen (ab SQL Server 2016)

CREATE TABLE Artikel (
    ArtikelID INT PRIMARY KEY,
    Name NVARCHAR(100),
    Preis DECIMAL(10,2),
    GültigVon DATETIME2 GENERATED ALWAYS AS ROW START,
    GültigBis DATETIME2 GENERATED ALWAYS AS ROW END,
    PERIOD FOR SYSTEM_TIME (GültigVon, GültigBis)
)  
WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.Artikel_Historie));

SQL Server führt automatisch Buch über Änderungen. Du kannst später bequem zurückblicken:

SELECT *
FROM Artikel
FOR SYSTEM_TIME AS OF '2023-01-01 00:00:00'
WHERE ArtikelID = 123;

Klingt nach Magie. Ist einfach gut gemacht.

Beispiel 3: Snapshot bei Periodenwechsel

Du brauchst keine lückenlose Historie? Dann reichen Snapshots.

SELECT *
INTO Archiv_Bestand_2024_01
FROM Lagerbestand
WHERE Standort = 'Zentral';

Das kannst Du automatisieren – z. B. per SQL-Agent-Job oder PowerShell.

Archivierte Daten nutzbar machen

Ein Archiv bringt nur was, wenn Du’s auch auswerten kannst.

• Einheitliche Formate (gleiche Spalten wie Original)
• Zeitbezug immer mit erfassen
• Views zur einfachen Abfrage
• Power BI oder Excel-Anbindung

Beispiel für eine konsolidierte Sicht:

CREATE VIEW vKunden_Chronik AS
SELECT KundenID, Name, Adresse, Änderungsdatum, Aktion
FROM Kunden_Archiv
UNION ALL
SELECT KundenID, Name, Adresse, NULL AS Änderungsdatum, 'C' AS Aktion
FROM Kunden;

Jetzt kannst Du jederzeit sehen, was sich wann geändert hat – oder eben nicht.

Tabelle: Was eignet sich wann?

Methode	Vorteil	Nachteil
Trigger	Flexibel, individuell	Pflegeaufwand, Fehleranfällig
Temporale Tabellen	Integriert, sauber	Nur ab SQL 2016, nicht für alles
Snapshots	Schnell, einfach	Lückenhaft, keine Änderungsdetails
CDC / Log Shipping	Vollständig, systemnah	Komplex, nicht auswertbar ohne Tools

Also

Ich bau Architekturen so, dass ich auch noch in 3 Jahren nachvollziehen kann, warum etwas passiert ist.

Du auch?

Dann bau Dir ein Archiv. Und zwar nicht erst, wenn das erste Gerichtsschreiben kommt.