Temporal Tables (Systemseitige Historytabelle)

[Gutmann]

Als ich über ein Feature namens Temporal Tables gelesen habe dachte ich mir "Oh klasse".

Kann es sein, dass es aber ausschließlich für z/OS und nicht für unsere kleine AS400 mit V7RX verfügbar ist?

Mit dieser Technologie wäre das manuelle Triggerschreiben u. Historytabellen anlegen ein Thema der Vergangenheit, weil die Temporaltables nach der Erzeugung sich automatisch darum kümmern würden.

Quelle:
http://www.ibm.com/developerworks/da...zos/index.html

Falls jemand Erfahrungen mit dem Umgang der TT hat, kann er dies auch gerne mitteilen.

[Fuerchau]

Das gab es doch schon immer, in dem ich Dateien (PF's) in die QTEMP stellen konnte.
Mit SQL gehts per "DECLARE GLOBAL TEMPORARY TABLE MyTable ....".
Das gibt es bereits seit V5R4.

[BenderD]

... nicht zu verwechseln:
- temporary tables (temporäre Tabellen, verschwinden automatisch wieder)
- temporal tables (Tabellen mit Zeitbezug, führen Historie mit)
letzteres geht auch mit DB2/400, ist aber aufwändig. Wieviel da DB2 auf Mainframe an Erleichterung bringt, entzieht sich meiner Kenntnis (da sind oft Kleinigkeiten aufwändig!). Ob und wann sowas für die anderen DB2 Varianten kommt, ist eine Frage des Marketings, ich würde da mal nicht drauf hoffen (die Partitionierung auf der AS/400 taugt auch nicht wirklich was).

D*B

[Fuerchau]

Entschuldigung, das wars nicht.

In V7R3 gibt es folgenden Tabellenfunktion:
ADD VERSIONING USE HISTORY TABLE
Genau damit sollte das dann gehen.
Nachzulesen im aktuellen V7R3-SQL-Referenzhandbuch.

[BenderD]

... nur mal einen Blick drauf geworfen: ist wohl weniger als Z, aber immerhin. Was es wirklich wert ist, erfordert wohl etwas sorgfältigeres nachsehen. Spannend wird es ja, wenn historische Bezüge über mehrere Tabellen gehen, also gejoined werden müssen. (Bestellung xyz mit Artikel, Kunde, etc. zum Zeitpunkt der Bestellung). Im richtigen Leben (Stichwort: Daten-Karstadt) haben wir da zusätzliche VersionsIds benutzt, um die Bezüge zu einem bestimmten Zeitpunkt zu vernageln.

D*B

[S.Neinawaie]

Hallo

Wie bereits erwähnt ist diesese Feature ab V7R3 verfügbar.

Beispiel inkl. näherer Beschreibung findest du unter

http://www.ibm.com/support/knowledge...poraltable.htm
http://www.ibm.com/support/knowledge...poraltable.htm

LG,
Sam

Nachtrag:

... nur mal einen Blick drauf geworfen: ist wohl weniger als Z, aber immerhin. Was es wirklich wert ist, erfordert wohl etwas sorgfältigeres nachsehen. Spannend wird es ja, wenn historische Bezüge über mehrere Tabellen gehen, also gejoined werden müssen. (Bestellung xyz mit Artikel, Kunde, etc. zum Zeitpunkt der Bestellung). Im richtigen Leben (Stichwort: Daten-Karstadt) haben wir da zusätzliche VersionsIds benutzt, um die Bezüge zu einem bestimmten Zeitpunkt zu vernageln.

D*B

Falls alle relevanten Tabellen historisiert werden sollte diese Abfrage kein Problem darstellen.
Es ist "nur" nötig vorher die entsprechende Umgebungszeit zu setzen.

Zitat aus einer Präsentation von Scott Forstie:

Produce an inventory report using a different point in time
SET CURRENT TEMPORAL SYSTEM_TIME '2016-03-22 17:00:00';
CALL GENERATE_INVENTORY_REPORT();

Weitere Infos zu "set Current Temporal System_Time":
http://www.ibm.com/support/knowledge...registerex.htm
http://www.ibm.com/support/knowledge...systemtime.htm

[Gutmann]

Vielen Dank für die zahlreichen Antworten. Leider haben wir noch V7R2 - knapp daneben.

Ich glaube ich werde wohl eine zentrale Tabelle basteln in der wichtige Programme ihre Aktionen protokollieren können, um somit dem Benutzer eine Art Verlauf in die Hand zu geben.

Ziel soll sein, dass der Benutzer sieht, wann, wer, etwas geändert hat.

Ich dachte an solch einen standardisierten / flexiblen Aufbau:

EventTable
-----------------
ID
SCHEMA
TABLENAME
ACTION
PROPERTY -- evtl. s. Kommentar unten
COLUMN -- evtl. s. Kommentar unten
VALUE
CHANGED
JOBUSER

Die Unterscheidung COLUMN u. PROPERTY habe ich deshalb vorgesehen, da der Feldname der Tabelle nicht zwangsläufig der Eigenschaft in der Klasse entsprechen muss.

Das soll dann weniger als Journal bzw. Restoremöglichkeit dienen, als viel mehr - ich wiederhole mich - dem Endanwender die Möglichkeit geben, eine Art Verlauf anzeigen zu können (wer hat wann was geändert).

Pro Tabelle immer Trigger anlegen etc. ist zwar sicherlich "sicherer" gegen Manipulation, mir geht's hier aber eher darum, dass ich ein standardisiertes Verfahren entwerfen kann um eine Art Log anlegen zu können.

Evtl. wäre es ratsam, ich speichere auch den Wert des Primärkeys der betroffenen Tabelle, sodass ich den Datensatz eindeutig identifizieren kann. Den alten Datensatz speichere ich dann komplett als XML-Objekt (C#) in der Spalte VALUE meiner Eventtabelle. Dann müsste ich nicht pro ColumnChanged einen Insert abfeuern (Speicherexplosion), allerdings würde dann das Log natürlich nicht nur die geänderten Eigenschaften anzeigen, sondern wirklich den kompletten Satz.

Haltet ihr so ein Konstrukt für gut/schlecht/gefährlich oder hat jemand eigene Erfahrungen in der Richtung?

[Fuerchau]

Alles was hierzu ohne Trigger protokolliert werden soll ist in soweit "gefährlich", als dass Änderungen am Programm vorbei nicht protokolliert werden.
Da für solche Aktionen i.d.R ja nur Stammdaten protokolliert werden sollen, macht es nur Sinn, Tabelle für Tabelle einen Trigger zu erstellen und genau die Felder zu protokollieren, um die es geht.
Es gibt häufig ja interne Felder, Fortschrittsfelder o.ä., die sicherlich nicht der Protokollierung bedürfen.
Wenn du das Ganze auch noch per C# weit weg vom System machst, wächst natürlich die Gefahr und, was ggf. auch nicht zu verachten ist, der Overhead zwischen Server und Client.

Deshalb hat man ja (u.A.) Trigger erfunden, um Aktionen durch zu führen, die unabhängig von den Anwendungsprogrammen sind.

Und zu guter letzt ist Journalisierung und Transaktionssteuerung da sicherlich auch erforderlich.

[BenderD]

... das ist faktisch nicht auswertbar, oder man bräuchte wieder einen Mechanismus, der die Daten für eine Tabelle restrukturiert. Haupt Nachteil der Systemhistorie ist einmal, dass hier eventuell "Blindänderungen" neue Versionen erzeugen (wie Baldur bereits anmerkte) und dass das immer nach Änderungstimestamp (:= wann hat die Änderung stattgefunden) geht und damit sowohl Änderungen in der Zukunft (ab wann soll der neue Preis gelten), als auch rückwärtige Änderungen nicht unterstützt werden.
Ich würde - wenn ich das brauche - die Tabellen insgesamt Zeitbezogen machen, sprich: die giltVon, giltBis und VersionsNr. aufnehmen und selber pflegen.

D*B

[Robi]

Wir arbeiten (zumindest in unserer Anwendung) mit schreib/lese Pgmmen. In keinem Pgm wird eine Datei gelesen oder geschreiben.
Trigger schreiben für (definierte) Dateien das orginal in die History.
Satzaufbau wie orginal + User Datum Zeit.
Lesepgmme für die History stehen in einer anderen Lib
HistoryLesepgmme machen statt Chain setll read und haben zusätzlich Datum/Zeit, gesetzt aus einer Dtaara, im Key. (als gültig ab!)
Bei setll / setgt und read wird ebenfals anders gelesen um immer den richtigen Satz zu erwischen.
(teilweise sehr aufwendig!)

So können wir duch verändern der Liblist und ändern einer Dtaara den Datenstand zu jeder Zeit ansehen. War recht aufwendig bis es lief!
Nachteil: Wenn einzelde Dateien sich im nachhinein als wichtig herausstellen stimmt die Anzeige nicht.
Reog Pgmme, nötig um das Datenvolumen einigermassen zu begrenzen.

richtig gebraucht habe wir das 3 - 4 mal in 10 Jahren!
unterm strich war der Aufwand zu groß, würde heute journalisieren und diese Daten auswerten

Robi

[Gutmann]

Danke für die drei Antworten. Ich denke hier werden wir dann weiterhin mit Triggern arbeiten.

[BenderD]

... ein klassischer Fall für das generieren der Trigger. Ansonsten empfehle ich wegen effektiver Auswertbarkeit sowohl giltVon als auch giltBis Felder und eine Versionsnummer mit aufzunehmen.

D*B