DB2 - Datensatz-Caching mit Table-UDF

Hallo alle zusammen,

ich bin in der Ausbildung zum Anwendungsentwickler und stehe vor einem (für mich) recht komplizierten Problem.Die Software die mein Betrieb erstellt benutzt zum speichern der Daten eine DB2-Datenbank. Da für eine Funktion die Summe diverse Datensätze mehrere Tabellengefordert wird deren Berechnung mehrere Sekunden dauert, möchte ich die Ergebnisse nun in einer weiteren Tabelle zwischenspeichern.

Den Zugriff auf die zwischengespeicherte Summe stelle ich über eine Scalar-Funktion bereit diedie Summe aus der Tabelle ausliest oder sofern noch keine zwischengespeicherter Wert vorhanden ist direkt berechnet. Sollte letzteres der Fall sein möchte ich den berechneten Wert innerhalb dieser Funktion in der "Cache"-Tabelle speichern um bei erneuten Zugriffen die Zugriffszeit zu beschleunigen und die Berechnung zu überspringen.

Letztendlich bin ich auf Table-UDFs gestoßen die mir das verändern von Tabellen (in meinem Fall einen INSERT) erlauben. Da der Rückgabewert dieser Funktion eine Tabelle ist, habe ich vor diese UDF in einem Viewmit den anderen relevanten Tabellen zu joinen was in einem Test-SELECT-Statement auch einwandfrei funktioniert. Sobald ich aber einen VIEW erstellen möchte werde ich von DB2 darauf hingewiesen, dass ich keine modifizierende Table-UDF in einer VIEW-Definition verwenden darf.

Leider habe ich nun keinen Ansatz mehr dieses Problem zu lösen. Ich habe gehofft in einem Datenbankforum wie diesem einige Ansätze zur Problemlösung zu finden.

Sollte also jemand mein Problem verstanden haben würde ich mich auf eine Rückmledung und ggf. eine Idee wie ich dieses lösen könnte sehr freuen.

Vielen Dank im voraus

 

Vorweg: ich habe NULL Ahnung von DB2, aber an Deiner Stelle würde ich zuerst einmal schauen, warum die Berechnung so lange dauert. DB2 hat sicher auch ein EXPLAIN, hast das schon mal angeschaut? Vielleicht fehlen ja nur 'nur' passende Indexe.

Das ist nicht ganz ungefählich, denn wenn sich Deine Ausgangstabellen ändern, ist Deine 'Cache' nicht mehr valide.

Bin mir nicht sicher, ob ich es richtig verstanden habe, aber es klingt für mich eher als ob Du via einem TRIGGER auf deinen Ausgangstabellen eine 'Cache-Tabelle' aktuell halten willst. Das aber erst nach Analyse, warum die Berechnung so lange braucht.


Andreas

 

Sorry für die fehlende Infos >.<:
Die Tabellen sind extrem groß (ca. 50 Mio. Datensätze) und Indexe sind sinnvoll gesetzt. Das ursprüngliche SQL ist soweit möglich bereits optimiert daher bin ich nun dabei das ganze zu cachen.

Die Cache-Tabelle wird wie du sagst durch Trigger stets aktuell gehalten nachdem ein Datensatz angelegt wurde.

Es handelt sich dabei genauer gesagt um zwei Tabellen: die "Konten"-Tabell und die "Umsatzdaten"-Tabelle. Ein Konto kann logischerweise mehrere Umsätze haben. Die Konten-Tabelle wird monatlich vom Kunden neu befüllt und daher wird auch die Cache-Tabelle monatlich geleert. Trigger sind auf der Umsatzdaten-Tabelle die dafür sorgt das der Wert eines Umsatzes subtrahiert wird sollte ein Umsatz-Datensatzentferntwerden.

Mein vorheriger Ansatz war es, alles über Trigger (zum Erstellen des Cache-Datensatzes eben ein INSERT-Trigger auf die Konten-Tabelle) zu realisieren. Da aber beim monatlichen befüllen der Konten-Tabelle die Dauer dieses Vorgangs durch meine Trigger von 3 Stunden auf 21 Stunden gestiegen ist suche ich nun mit diesem oben beschriebenen Ansatz nach einer effizienteren Lösung indem ich nur Konten zwischenspeichere die auch angefasst werden und bei denen die Summierung der Umsatzdaten demnach nötig ist.

Danke für deine Antwort!

 

• TRIGGER ausschalten beim Befüllen?
• conditional TRIGGER (gibt es in PG, weiß nicht, ob DB2 das hat)

 

Die Trigger bewirken ja aber, dass der Datensatz "vorberechnet" wird. Schalte ich diesen aus habe ich keinen Datensatz in der Cache-Tabelle. Diesen Ansatz verfolge ich derzeit mein Problem ist wie im ersten Post erklärt, dass ich nicht weiß ich wie einen noch nicht vorhandenen gecacheden Datensatz nach der Berechnung in die Cache-Tabelle bekomme.

Conditional Trigger sagt mir nichts, werd mich mal umschauen, danke

 

Naja, ich meinte, erst mal alles in die Tabelle werfen und dann in einem Zug Deine Cache-Tabelle berechnen und dann die TRIGGER wieder freischalten.


Conditional TRIGGER, in PG geht es so:

http://www.postgresql.org/docs/9.2/static/sql-createtrigger.html

achte auf [ WHEN ( condition ) ] , die Doku erklärt den Rest.

Andreas

 

Problem wäre ja, dass die Berechnung die direkt danach kommt auch ziemlich lange dauern würde und es somit relativ wenig bringt den Trigger davor zu deaktivieren. Es werden ebenfalls Daten berechnet die evntl. nicht benötigt werden.

Werde mir das mal anschauen und ausprobieren, danke.