In meinem Blogartikel Inkrementelles Laden mit Hilfe von Hashfunktionen habe ich unter anderem über die Berechnung des Deltas nach der Datenlieferung gesprochen. Diese sollte performant sein und auch für sehr große Tabellen funktionieren. Um die Anzahl der zu vergleichenden Spalten zu reduzieren wurde die Hashfunktion eingeführt. Aber was ist mit der Anzahl der Zeilen? Wie oft müssen die Tabellen beim Vergleich mit Full-Table-Scan gelesen und sortiert werden? Und die Inserts, Updates und Deletes müssen ja auch noch identifiziert und gekennzeichnet werden. Schauen wir uns das an.

Intuitives Vorgehen beim Tabellenvergleich

Jeder von uns hat schon mal nach Differenzen in zwei Tabellen suchen müssen. Das geht ungefähr so:

Nun, so ganz stimmt es noch nicht. In der ersten Menge sind sowohl Zeilen, die neu hinzugekommen sind, als auch die geänderten. Und in der zweiten sind sowohl die geänderten als auch die gelöschten Sätze. Um die geänderten Zeilen identifizieren zu können, müssen wir Schlüsselspalten und Wertspalten unterscheiden:

Ich habe die letzte Unterabfrage bewusst nicht ausgeschrieben. Zum einen gibt es mehrere Möglichkeiten, die benötigten Daten abzufragen. Zum anderen sieht man bereits jetzt, wo es hinführt. Die Anzahl der Full Table Scan Zugriffe lag in der ersten Variante bereits bei vier (zwei pro Tabelle). In der zweiten Variante kommen noch mindestens drei hinzu. Und jeder MINUS Operator führt zu einer SORT-Operation. Auch wenn die in meinem Beispiel aus einer einzigen Hash-Spalte bestanden, würde eine solche Abfrage ab einer bestimmten Zeilenanzahl zu unnötigen Performanceproblemen führen. Es muss doch möglich sein, die Tabellen jeweils nur einmal zu lesen, um die benötigten Daten zu erzeugen! Und so geht’s:

Gruppieren statt Sortieren

Die Idee ist, alle Daten einmal zu selektieren und mit Hilfe von zusätzlich gesetzten Kennzahlen zu aggregieren und zu filtern. Die Vorgehensweise ist gewöhnungsbedürftig und beim ersten mal nicht direkt intuitiv verständlich, aber sie hat sich für mich bereits in mehreren Projekten bewährt. Auch bei der Deltaberechnung kam sie erfolgreich zum Einsatz. Wie man sieht, werden die beiden Tabellen nur einmal gelesen. Die Logik ist recht einfach und wird in den Kommentaren erklärt.

Fazit

Wie so oft im Leben ist der direkte oder der augenscheinlich einfachste Weg nicht immer der Beste. Auch für das altbewährte Vorgehen kann mit einer neuen Oracle Version eine bessere Alternative kommen. Es lohnt sich oft eine Lösung in Frage zu stellen und auch mal kreativ zu sein. Viel Spaß beim Ausprobieren!

Ähnliche Beiträge

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Bitte füllen Sie dieses Feld aus
Bitte füllen Sie dieses Feld aus
Bitte gib eine gültige E-Mail-Adresse ein.

Menü