Wer hat den Preis geändert, und wie hoch war er eigentlich vor drei Wochen? Wann ist dieser Datensatz gelöscht worden, und wie sah er kurz davor aus? Sobald eine Datenbank produktiv läuft, tauchen solche Fragen auf – und oft steht man mit leeren Händen da, weil die alten Werte längst überschrieben sind. Der klassische Ausweg ist eine selbstgebaute Historientabelle samt Triggern, die bei jedem INSERT<\/b>, UPDATE<\/b> und DELETE<\/b> die alte Zeile wegschreiben. Das funktioniert, ist aber Handarbeit. Der SQL Server bringt seit der Version 2016 eine eingebaute Lösung mit: System-Versioned Temporal Tables<\/b>. Die Datenbank führt die komplette Änderungshistorie vollautomatisch mit, und Abfragen zu einem beliebigen Zeitpunkt der Vergangenheit sind eine Zeile Zusatz-SQL<\/b>. Wie das gelingt, wie und wo die alten Daten landen und wie Du eine bestehende Tabelle nachträglich versionierst, liest Du in diesem Beitrag – und auch, was Temporal Tables nicht können.<\/b><\/p>\n
Was eine Temporal Table eigentlich ist<\/h2>\n
Eine systemversionierte temporale Tabelle besteht immer aus einem Paar: der aktuellen Tabelle, die – wie gewohnt – den jeweils gültigen Stand jeder Zeile enthält, und einer zugehörigen Historientabelle, in der jede frühere Version einer Zeile aufbewahrt wird. Beide zusammen ergeben eine lückenlose Zeitleiste.<\/p>\n
Damit der SQL Server weiß, ab wann und bis wann eine bestimmte Version einer Zeile gültig war, braucht die Tabelle zwei zusätzliche Spalten vom Typ DATETIME2<\/b>, die sogenannten Periodenspalten. Die eine hält den Startzeitpunkt (im Beispiel gleich GueltigVon<\/b>), die andere den Endzeitpunkt (GueltigBis<\/b>).<\/p>\n
Solange eine Zeile aktuell ist, steht in GueltigBis<\/b> der Maximalwert 9999-12-31 23:59:59.9999999<\/b> – der SQL Server liest das als “gilt bis auf Weiteres”.<\/p>\n
Ändern wir die Zeile, passiert im Hintergrund Folgendes: Die bisherige Version wandert mit ihrem echten Endzeitpunkt in die Historientabelle, und in der aktuellen Tabelle steht die neue Version mit frischem Startzeitpunkt. Wir müssen dafür nichts programmieren – kein Trigger, keine Prozedur.<\/p>\n
Ein Punkt vorweg, der später noch wichtig wird: Der SQL Server speichert diese Zeitstempel in UTC<\/b>, nicht in lokaler Zeit.<\/p>\n
Für uns in Deutschland heißt das ein bis zwei Stunden Versatz zur Uhr an der Wand. Darauf kommen wir bei den Abfragen zurück.<\/p>\n
Temporal Tables erstellen nur eine Kopie eines geänderten oder gelöschten Datensatzes und tragen ein, von wann bis wann dieser Datensatz gültig war. Wir können damit nicht automatisch eine Information hinterlegen, wer die neue Version des Datensatzes angelegt hat.<\/p>\n
Es wird für eine historisierte Version eines Datensatze auch nicht eingetragen, ob dieser Datensatz durch einen geänderten Datensatz ersetzt oder ob dieser gelöscht wurde – es wird lediglich jede geänderte oder gelöschte Version eines Datensatzes gespeichert.<\/p>\n
Bauen wir zunächst eine ganz normale Tabelle ohne jede Versionierung auf und füllen sie mit ein paar Datensätzen – so, wie eine bestehende Anwendung sie mitbringen könnte.<\/p>\n
Erst im nächsten Schritt rüsten wir die Historie nach. Das entspricht dem häufigsten Fall aus der Praxis: Die Tabelle ist längst da, die Historie soll dazu.<\/p>\n
Das erledigt Listing 1. Es legt die Datenbank TemporalDemo<\/b> an, darin die Tabelle tblProdukte<\/b> mit den Feldern ProduktID<\/b>, Bezeichnung<\/b> und Preis<\/b> – und füllt drei Zeilen ein.<\/p>\n Listing 1: Beispieldatenbank und Tabelle tblProdukte anlegen und mit Daten füllen<\/span><\/b><\/p>\n Ein Detail ist keine Kür, sondern Voraussetzung für alles Weitere: Die Tabelle tblProdukte<\/b> hat einen Primärschlüssel (PK_Produkt<\/b> auf ProduktID<\/b>). Ohne Primärschlüssel lässt sich später keine Systemversionierung einschalten – der SQL Server braucht ihn, um eine Zeile über ihre Versionen hinweg eindeutig zu verketten. Wer hier eine Tabelle ohne Schlüssel hat, muss also zuerst einen nachrüsten.<\/p>\n Jetzt kommt der eigentliche Schritt: Wir erweitern die bestehende Tabelle tblProdukte<\/b> um die beiden Periodenspalten und schalten die Systemversionierung ein.<\/p>\n Das geschieht in Listing 2 in zwei getrennten ALTER TABLE<\/b>-Anweisungen – erst die Spalten und die Periode, dann die Versionierung selbst.<\/p>\n Listing 2: Die bestehende Tabelle tblProdukte um Periodenspalten erweitern und die Systemversionierung einschalten<\/span><\/b><\/p>\n Das ist zugleich das allgemeine Rezept für jede Tabelle, die es in Deiner Datenbank schon gibt – einzige harte Voraussetzung bleibt der Primärschlüssel aus dem vorigen Abschnitt.<\/p>\n Gehen wir das durch, denn hier lauern gleich mehrere Stolpersteine. Die beiden neuen Spalten sind mit GENERATED ALWAYS AS ROW START<\/b> bzw. ROW END<\/b> gekennzeichnet – das sagt dem SQL Server, dass er diese Werte setzt und wir sie niemals von Hand befüllen.<\/p>\n Genau daraus ergibt sich das erste Problem: Die Spalten sind NOT NULL<\/b>, aber unsere Tabelle enthält bereits Daten. Woher soll der SQL Server die Zeitstempel für die drei vorhandenen Zeilen nehmen? Wir würden die Werte nun gern selbst eintragen – aber das ist bei GENERATED ALWAYS<\/b>-Spalten nicht möglich.<\/p>\n Die Lösung sind die beiden DEFAULT<\/b>-Constraints: Sie liefern die Startwerte für die schon vorhandenen Zeilen. Ohne diese Defaults bricht das ALTER TABLE<\/b> bei einer gefüllten Tabelle mit einer Fehlermeldung ab.<\/p>\n Der zweite Stolperstein steckt in der Wahl dieser Defaults. Für GueltigVon<\/b> nehmen wir SYSUTCDATETIME()<\/b>, also den aktuellen Zeitpunkt in UTC<\/b>. Für GueltigBis<\/b> muss es zwingend der Maximalwert 9999-12-31 23:59:59.9999999<\/b> sein – nicht etwa ebenfalls die aktuelle Zeit.<\/p>\n Der Endzeitpunkt markiert bei einer aktuellen Zeile das “gilt bis auf Weiteres”, und er muss größer sein als der Startzeitpunkt. Wer hier versehentlich auch SYSUTCDATETIME()<\/b> einsetzt, erntet einen Fehler.<\/p>\n Und der dritte Punkt ist weniger ein Fehler als eine ehrliche Einordnung: Die Historie beginnt in dem Moment, in dem wir die Versionierung einschalten. Unsere drei Bestandszeilen bekommen alle denselben Startzeitpunkt – den der Umstellung -, nicht ihr echtes Anlagedatum. Rückwirkend entsteht keine Historie, die vorher nie aufgezeichnet wurde. Das ist keine Schwäche des Verfahrens, aber gut zu wissen, bevor man sich über gleiche Zeitstempel wundert.<\/p>\n Die zweite Anweisung schaltet mit SET (SYSTEM_VERSIONING = ON …)<\/b> die Versionierung scharf und legt dabei die Historientabelle dbo.tblProdukteHistory<\/b> an. Den Namen geben wir bewusst selbst an. Lässt man ihn weg, erzeugt der SQL Server eine automatisch benannte Tabelle nach dem Muster MSSQL_TemporalHistoryFor_…<\/b> samt Objekt-ID – funktioniert, ist aber unhandlich.<\/p>\n Im Objekt-Explorer des SQL Server Management Studios erkennst Du das Ergebnis sofort: Die Tabelle tblProdukte<\/b> trägt jetzt ein kleines Uhr-Symbol, und darunter hängt als Unterknoten die zugehörige tblProdukteHistory<\/b> (siehe Bild 1). Im Kontextmenü sehen wir auch gleich, dass wir die Datensätze dieser Tabelle nicht bearbeiten können – es fehlt der Eintrag Oberste 200 Einträge bearbeiten<\/b>.<\/p>\n Bild 1: Der Objekt-Explorer zeigt die versionierte Tabelle Produkt mit Uhr-Symbol und der eingerückten Historientabelle ProduktHistory<\/span><\/b><\/p>\n Das war der Weg für eine Tabelle, die es schon gibt – der häufigste Fall in der Praxis. Steht die Tabelle dagegen noch gar nicht, gibt es einen kürzeren Weg, den wir uns weiter unten im Abschnitt zum direkten Anlegen ansehen.<\/p>\n Werfen wir einen Blick auf die Verteilung, bevor überhaupt etwas geändert wurde. Die aktuelle Tabelle tblProdukte<\/b> enthält unsere drei Zeilen, die Historientabelle tblProdukteHistory<\/b> ist noch leer – logisch, denn es gibt ja noch keine früheren Versionen. Erst eine Änderung füllt die Historie.<\/p>\n Wichtig ist die Rollenverteilung: In der aktuellen Tabelle steht immer nur der jeweils gültige Stand. Jede überschriebene oder gelöschte Version zieht in die Historientabelle um.<\/p>\n Diese ist eine ganz normale Tabelle, die Du direkt abfragen kannst – nur ändern darfst Du sie nicht, solange die Versionierung eingeschaltet ist. Der SQL Server verwaltet ihren Inhalt allein.<\/p>\n Und noch einmal der Hinweis auf die Zeitzone, weil er gleich praktisch wird: Die Werte in GueltigVon<\/b> und GueltigBis<\/b> stehen in UTC<\/b>. Ein Datensatz, der um 14:00 Uhr deutscher Sommerzeit geändert wird, trägt in der Historie den Zeitstempel 12:00 Uhr.<\/p>\n Damit die Historie etwas zu zeigen hat, spielen wir ein kleines Szenario durch: Der Kaffee wird teurer, die Teekanne kommt in den Ausverkauf, und das Espressotassen-Set fliegt aus dem Sortiment.<\/p>\n Listing 3 setzt genau das um. Die WAITFOR DELAY<\/b>-Zeilen sind nur für unser Beispiel gedacht: Sie sorgen dafür, dass die drei Änderungen deutlich auseinanderliegende Zeitstempel bekommen, damit die Zeitpunkt-Abfragen gleich anschaulich werden. Im echten Betrieb entstehen diese Abstände von selbst.<\/p>\n Listing 3: Datensätze ändern und löschen, damit die Historie sich füllt<\/span><\/b><\/p>\n Nach diesem Durchlauf zeigt eine gewöhnliche Abfrage auf tblProdukte<\/b> nur noch zwei Zeilen – den Kaffee zu 13,90<\/b> und die Teekanne zu 29,90<\/b>. Das Espressotassen-Set ist verschwunden. Aus der aktuellen Tabelle, wohlgemerkt: In der Historie lebt es weiter.<\/p>\n Jetzt kommt der Lohn der Mühe. Um an die Historie zu kommen, hängen wir an die Tabelle die Klausel FOR SYSTEM_TIME<\/b> an. Verschaffen wir uns zuerst einen Gesamtüberblick über alle Versionen – aktuelle und historische zusammen – mit FOR SYSTEM_TIME ALL<\/b>. Das zeigt Listing 4.<\/p>\n Listing 4: Aktueller Stand und komplette Zeitleiste mit FOR SYSTEM_TIME ALL<\/span><\/b><\/p>\n Die zweite Abfrage liefert die vollständige Zeitleiste: Für den Kaffee erscheinen zwei Zeilen (12,90<\/b> mit einem geschlossenen Gültigkeitsfenster, 13,90<\/b> mit offenem Ende 9999-12-31 …<\/b>), für die Teekanne ebenso, und das gelöschte Espressotassen-Set taucht mit einem abgeschlossenen Fenster wieder auf – obwohl es in der aktuellen Tabelle gar nicht mehr existiert. An den Werten in GueltigVon<\/b> und GueltigBis<\/b> lässt sich ablesen, welche Version wann galt (siehe Bild 2).<\/p>\n Bild 2: FOR SYSTEM_TIME ALL zeigt zu jedem Produkt sämtliche Versionen mit ihren Gültigkeitsfenstern in den Spalten GueltigVon und GueltigBis<\/span><\/b><\/p>\n Für die eigentliche Zeitpunkt-Frage – “Wie sah das Sortiment zu einem bestimmten Moment aus?” – gibt es FOR SYSTEM_TIME AS OF<\/b>. Der SQL Server liefert dann von jeder Zeile genau die Version zurück, die zum angegebenen Zeitpunkt gültig war. Listing 5 zeigt die Varianten.<\/p>\n Listing 5: Abfragen zu einem Zeitpunkt und über einen Zeitraum mit FOR SYSTEM_TIME<\/span><\/b><\/p>\n Der Zeitpunkt in der AS OF<\/b>-Abfrage ist frei erfunden – Deine eigenen Zeitstempel liegen anders, je nachdem, wann Du die Listings ausführst.<\/p>\n Am einfachsten nimmst Du einen der Werte, die Dir die ALL<\/b>-Abfrage aus dem vorherigen Listing in GueltigVon<\/b> oder GueltigBis<\/b> angezeigt hat, und setzt einen Moment davor oder dazwischen ein.<\/p>\n Fragst Du einen Zeitpunkt vor allen Änderungen ab, liefert der SQL Server den Ursprungsstand – Kaffee zu 12,90<\/b>, Teekanne zu 34,50<\/b> und das Espressotassen-Set noch im Sortiment (siehe Bild 3).<\/p>\n Bild 3: Dieselbe Tabelle, per FOR SYSTEM_TIME AS OF zu einem Zeitpunkt vor den Änderungen abgefragt – die alten Preise und das gelöschte Produkt sind wieder da<\/span><\/b><\/p>\n Und hier schlägt der eingangs erwähnte Zeitzonen-Stolperstein zu: Der Wert hinter AS OF<\/b> wird als UTC<\/b> interpretiert. Fragst Du im deutschen Sommer AS OF ‘2026-07-22 14:00:00’<\/b> ab, meinst Du vielleicht 14 Uhr Ortszeit – der SQL Server versteht aber 14 Uhr UTC, also 16 Uhr bei uns.<\/p>\n Zwei Stunden daneben, und schon bekommst Du eine andere Version zurück oder gar keine. Wer sauber arbeiten will, denkt bei diesen Abfragen konsequent in UTC oder rechnet den Versatz bewusst heraus.<\/p>\n Neben AS OF<\/b>, BETWEEN … AND<\/b> und CONTAINED IN<\/b> gibt es noch FROM … TO<\/b> mit leicht anderem Randverhalten an den Intervallgrenzen; für den Alltag sind AS OF<\/b> (ein Zeitpunkt) und ALL<\/b> (die ganze Geschichte) die beiden Arbeitspferde.<\/p>\n Bisher sind wir den Nachrüst-Weg gegangen: erst die fertige Tabelle tblProdukte<\/b>, dann die Versionierung obendrauf.<\/p>\n Das ist der häufigste Fall, weil die Tabellen meist schon da sind. Legst Du eine Tabelle dagegen frisch an, sparst Du Dir das zweistufige ALTER TABLE<\/b> und machst sie gleich beim Anlegen temporal. Die Periodenspalten und die WITH (SYSTEM_VERSIONING = ON …)<\/b>-Klausel wandern dann direkt ins CREATE TABLE<\/b>, wie Listing 6 an einer neuen Tabelle tblKunden<\/b> zeigt.<\/p>\n Listing 6: Die neue Tabelle tblKunden gleich temporal anlegen<\/span><\/b><\/p>\n Der Unterschied zum Nachrüsten fällt angenehm aus: Weil die Tabelle tblKunden<\/b> von Anfang an leer ist, brauchen wir keine DEFAULT<\/b>-Constraints für vorhandene Zeilen – die beiden Stolpersteine von vorne entfallen komplett.<\/p>\n Die Periodenspalten stehen einfach mit in der Spaltenliste, und die WITH<\/b>-Klausel schaltet die Versionierung im selben Rutsch ein. Alles Übrige – die Historientabelle tblKundenHistory<\/b>, das automatische Wegschreiben, die Abfragen mit FOR SYSTEM_TIME<\/b> – funktioniert danach genau wie bei tblProdukte<\/b>.<\/p>\n Die beiden Periodenspalten sind im Alltag selten interessant – bei einem gewohnten SELECT *<\/b> liefern sie nur zwei technische Zeitstempel mit, nach denen niemand gefragt hat. Der SQL Server kann sie deshalb verbergen: Das Schlüsselwort HIDDEN<\/b> blendet eine Periodenspalte aus, ohne sie abzuschaffen.<\/p>\n Sie bleibt voll funktionsfähig, verschwindet aber aus dem Ergebnis von SELECT *<\/b> und taucht nur noch auf, wenn wir sie ausdrücklich benennen.<\/p>\n An unserer bestehenden Tabelle tblProdukte<\/b> schalten wir das mit ALTER COLUMN … ADD HIDDEN<\/b> nachträglich ein. Das zeigt Listing 7 samt einem Vorher-Nachher, an dem der Effekt sichtbar wird.<\/p>\n Listing 7: Die Periodenspalten mit HIDDEN aus SELECT * ausblenden<\/span><\/b><\/p>\n Nach dem Ausführen fällt der Unterschied sofort auf: Das erste SELECT *<\/b> gibt nur noch die drei fachlichen Spalten ProduktID<\/b>, Bezeichnung<\/b> und Preis<\/b> zurück, während die zweite Abfrage die Zeitstempel klaglos weiterliefert. Die Daten sind also nicht weg, sondern nur aus dem Weg. Möchtest Du die Spalten wieder einblenden, drehst Du das mit DROP HIDDEN<\/b> um:<\/p>\n Wer eine Tabelle ohnehin neu anlegt, spart sich diesen Umweg und schreibt HIDDEN<\/b> direkt hinter ROW START<\/b> beziehungsweise ROW END<\/b> in die Spaltendefinition. Allerdings eine ehrliche Einordnung: SELECT *<\/b> ist im Produktivcode ohnehin verpönt, und so ist HIDDEN<\/b> eher Komfort für die interaktive Arbeit in SSMS als eine echte Notwendigkeit. Bleibt der Fall, dass Du am Schema etwas ändern musst, das der SQL Server bei eingeschalteter Versionierung blockiert. Dann schaltest Du sie kurz ab:<\/p>\n Danach sind tblProdukte<\/b> und tblProdukteHistory <\/b>wieder zwei ganz normale, entkoppelte Tabellen – die Historie bleibt erhalten, wird aber bis zum Wiedereinschalten nicht mehr fortgeschrieben. Anschließend schaltest Du mit der ON<\/b>-Variante wieder ein. Genau so löscht man eine temporale Tabelle auch: erst OFF<\/b>, dann beide Tabellen einzeln entfernen.<\/p>\n Systemversionierte temporale Tabellen nehmen uns die komplette Handarbeit der Historienführung ab. Wir haben eine bestehende Tabelle tblProdukte<\/b> um zwei Periodenspalten erweitert, die Versionierung mit einer zugehörigen Historientabelle tblProdukteHistory<\/b> eingeschaltet und gesehen, wie der SQL Server bei jeder Änderung die alte Version automatisch wegschreibt.<\/p>\n Dabei haben wir beide Wege gesehen: das Nachrüsten an einer schon vorhandenen Tabelle per ALTER TABLE<\/b> und das direkte temporale Anlegen einer neuen Tabelle im CREATE TABLE<\/b>. Mit FOR SYSTEM_TIME<\/b> – vor allem AS OF<\/b> für einen Zeitpunkt und ALL<\/b> für die ganze Zeitleiste – lässt sich der Datenbestand zu jedem vergangenen Moment abfragen, und mit HIDDEN<\/b> halten wir die technischen Periodenspalten bei Bedarf aus dem Blick.<\/p>\n Die beiden wichtigsten Fallstricke: der Primärschlüssel als Voraussetzung und die UTC<\/b>-Speicherung der Zeitstempel.<\/p>\n Damit sind einige Themen nur angerissen, die eigene Beiträge verdienen. Wie hält man die Historientabelle langfristig klein, ohne von Hand aufzuräumen? Der SQL Server kann Verlaufsdaten über einen HISTORY_RETENTION_PERIOD<\/b> automatisch nach Ablauf löschen – ein Folgeartikel wert.<\/p>\n Ebenso spannend: Wie greift man aus einem Access-Frontend auf diese Historie zu und zeigt sie in einem Formular oder Bericht an – hier verbinden sich die Access- und die SQL-Welt auf natürliche Weise. Und wer es fälschungssicher braucht, findet in den Ledger Tables<\/b> der neueren SQL-Server-Versionen die konsequente Weiterentwicklung des Gedankens. Wie Du die Historie aus Access heraus nutzbar machst, zeigt einer der nächsten Beiträge.<\/p>\n","protected":false},"excerpt":{"rendered":" Wer hat den Preis geändert, und wie hoch war er eigentlich vor drei Wochen? Wann ist dieser Datensatz gelöscht worden, und wie sah er kurz davor aus? Sobald eine Datenbank produktiv läuft, tauchen solche Fragen auf – und oft steht man mit leeren Händen da, weil die alten Werte längst überschrieben sind. Der klassische Ausweg ist eine selbstgebaute Historientabelle samt Triggern, die bei jedem INSERT, UPDATE und DELETE die alte Zeile wegschreiben. Das funktioniert, ist aber Handarbeit. Der SQL Server bringt seit der Version 2016 eine eingebaute Lösung mit: System-Versioned Temporal Tables. Die Datenbank führt die komplette Änderungshistorie vollautomatisch mit, und Abfragen zu einem beliebigen Zeitpunkt der Vergangenheit sind eine Zeile Zusatz-SQL. Wie das gelingt, wie und wo die alten Daten landen und wie Du eine bestehende Tabelle nachträglich versionierst, liest Du in diesem Beitrag – und auch, was Temporal Tables nicht können.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[662026,66032026,44000006],"tags":[],"yst_prominent_words":[],"class_list":["post-55000513","post","type-post","status-publish","format-standard","hentry","category-662026","category-66032026","category-SQL_Server_und_Co"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\tCREATE DATABASE TemporalDemo;\r\nGO\r\nUSE TemporalDemo;\r\nGO\r\nCREATE TABLE dbo.tblProdukte\r\n(\r\n ProduktID INT IDENTITY(1,1) NOT NULL CONSTRAINT PK_Produkt PRIMARY KEY CLUSTERED,\r\n Bezeichnung NVARCHAR(100) NOT NULL,\r\n Preis DECIMAL(10,2) NOT NULL\r\n);\r\nGO\r\nINSERT INTO dbo.tblProdukte (Bezeichnung, Preis)\r\nVALUES (N'Kaffeebohnen Brasil', 12.90),\r\n (N'Teekanne Gusseisen', 34.50),\r\n (N'Espressotassen-Set', 19.99);\r\nGO<\/pre>\n
Versionierung an einer bestehenden Tabelle nachrüsten<\/h2>\n
USE TemporalDemo;\r\nGO\r\nALTER TABLE dbo.tblProdukte ADD\r\n GueltigVon DATETIME2(7) GENERATED ALWAYS AS ROW START NOT NULL\r\n CONSTRAINT DF_Produkt_GueltigVon DEFAULT SYSUTCDATETIME(),\r\n GueltigBis DATETIME2(7) GENERATED ALWAYS AS ROW END NOT NULL\r\n CONSTRAINT DF_Produkt_GueltigBis\r\n DEFAULT CONVERT(DATETIME2(7), '9999-12-31 23:59:59.9999999'),\r\n PERIOD FOR SYSTEM_TIME (GueltigVon, GueltigBis);\r\nGO\r\nALTER TABLE dbo.tblProdukte\r\n SET (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.tblProdukteHistory));\r\nGO<\/pre>\n
![\"Der](\"..\/fileadmin\/_temp_\/2026_03\/pic_513_001.png\")
<\/p>\nWo die alten Daten landen<\/h2>\n
Daten verändern und die Historie beobachten<\/h2>\n
USE TemporalDemo;\r\nGO\r\nUPDATE dbo.tblProdukte SET Preis = 13.90 WHERE Bezeichnung = N'Kaffeebohnen Brasil';\r\nWAITFOR DELAY '00:00:03';\r\nUPDATE dbo.tblProdukte SET Preis = 29.90 WHERE Bezeichnung = N'Teekanne Gusseisen';\r\nWAITFOR DELAY '00:00:03';\r\nDELETE FROM dbo.tblProdukte WHERE Bezeichnung = N'Espressotassen-Set';\r\nGO<\/pre>\n
Abfragen zu einem Zeitpunkt mit FOR SYSTEM_TIME<\/h2>\n
USE TemporalDemo;\r\nGO\r\n-- Nur der aktuelle Stand (ganz normale Abfrage):\r\nSELECT ProduktID, Bezeichnung, Preis, GueltigVon, GueltigBis\r\nFROM dbo.tblProdukte\r\nORDER BY ProduktID;\r\n-- Alle Versionen, aktuell und historisch:\r\nSELECT ProduktID, Bezeichnung, Preis, GueltigVon, GueltigBis\r\nFROM dbo.tblProdukte FOR SYSTEM_TIME ALL\r\nORDER BY ProduktID, GueltigVon;\r\nGO<\/pre>\n
![\"FOR](\"..\/fileadmin\/_temp_\/2026_03\/pic_513_002.png\")
<\/p>\nUSE TemporalDemo;\r\nGO\r\n-- Stand zu einem bestimmten Zeitpunkt (Wert in UTC!):\r\nSELECT ProduktID, Bezeichnung, Preis\r\nFROM dbo.tblProdukte\r\nFOR SYSTEM_TIME AS OF '2026-07-22 09:00:00'\r\nORDER BY ProduktID;\r\n-- Alle Versionen, die in einem Zeitraum aktiv waren:\r\nSELECT ProduktID, Bezeichnung, Preis, GueltigVon, GueltigBis\r\nFROM dbo.tblProdukte\r\nFOR SYSTEM_TIME BETWEEN '2026-07-01' AND '2026-07-31'\r\nORDER BY ProduktID, GueltigVon;\r\n-- Nur Versionen, die komplett innerhalb des Zeitraums liegen:\r\nSELECT ProduktID, Bezeichnung, Preis, GueltigVon, GueltigBis\r\nFROM dbo.tblProdukte\r\nFOR SYSTEM_TIME CONTAINED IN ('2026-07-01', '2026-07-31')\r\nORDER BY ProduktID, GueltigVon;\r\nGO<\/pre>\n![\"Dieselbe](\"..\/fileadmin\/_temp_\/2026_03\/pic_513_003.png\")
<\/p>\nUnd wenn die Tabelle noch gar nicht existiert?<\/h2>\n
USE TemporalDemo;\r\nGO\r\nCREATE TABLE dbo.tblKunden\r\n(\r\n KundeID INT IDENTITY(1,1) NOT NULL\r\n CONSTRAINT PK_Kunde PRIMARY KEY CLUSTERED,\r\n Name NVARCHAR(100) NOT NULL,\r\n Ort NVARCHAR(100) NULL,\r\n GueltigVon DATETIME2(7) GENERATED ALWAYS AS ROW START NOT NULL,\r\n GueltigBis DATETIME2(7) GENERATED ALWAYS AS ROW END NOT NULL,\r\n PERIOD FOR SYSTEM_TIME (GueltigVon, GueltigBis)\r\n)\r\nWITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.tblKundenHistory));\r\nGO<\/pre>\n
Feinschliff: HIDDEN und Versionierung abschalten<\/h2>\n
USE TemporalDemo;\r\nGO\r\nALTER TABLE dbo.Produkt ALTER COLUMN GueltigVon ADD HIDDEN;\r\nALTER TABLE dbo.Produkt ALTER COLUMN GueltigBis ADD HIDDEN;\r\nGO\r\n-- Liefert jetzt nur noch ProduktID, Bezeichnung und Preis:\r\nSELECT * FROM dbo.Produkt;\r\n-- Die Periodenspalten sind weiterhin da - nur auf ausdrückliche Anfrage:\r\nSELECT ProduktID, Bezeichnung, Preis, GueltigVon, GueltigBis\r\nFROM dbo.Produkt;\r\nGO<\/pre>\n
ALTER TABLE dbo.Produkt ALTER COLUMN GueltigVon DROP HIDDEN;<\/pre>\n
ALTER TABLE dbo.Produkt SET (SYSTEM_VERSIONING = OFF);<\/pre>\n
Zusammenfassung und Ausblick<\/h2>\n