SQL:2003 sei Dank für eine Menge Zeit, die ich letzte Woche sparen konnte. Schuld daran waren vor allen "MERGE", aber auch eine mit "GENERATED ALWAYS AS IDENTITY" definierte Identitätsspalte.
Es wäre schon viel Schreib- und Testarbeit gewesen ohne "Merge" eine Tabelle mit Daten aus einer anderen zu aktualisieren. Das Einfügen neuer Zeilen wäre ja noch eine leichte Übung gewesen, aber für die Modifikation bereits vorhandener Zeilen habe ich bisher stets ein Programm schreiben müssen.
Das hat sich mit der aktuellen Version des SQL-Standards geändert: Nun ist es mit einer SQL-Anweisung möglich Daten in bestehenden Zeilen zu aktualisieren bei gleichzeitiger Erweiterung der Tabelle um neue Datensätze. Ich verwende "Merge" auch dann, wenn ich nur Daten zu bestehenden Schlüsseln ändern will.
Nun ist das so eine Sache mit den SQL-Standards: Viele sinnvolle Vorschläge sind in den aktuellen Versionen der gängigen Datenbanksystemen nicht umgesetzt. Das betrifft SQL:1999 und auch
SQL:2003. Andererseits versuchen einige DBMS-Hersteller durch proprietäre Ergänzungen der Datenbankfunktionalität Kunden an sich zu binden. Das betrifft vor allem Oracle, aber leider auch MySQL.
Im Falle von "Merge" liegt hier gleich beides vor: So kennen DB2 und Oracle DB die Merge-Anweisung bereits seit einigen Jahren, der SQL Server wird das "Mischen" von Tabellen wohl erst mit nächsten Version ermöglichen.
MySQL wiederum kennt eine Anweisung namens "Replace", die allerdings nicht so flexibel ist wie "Merge". Bei "Replace" handelt es sich um eine proprietäre Ergänzung, die kaum zum Standard erhoben werden wird. MySQL umschreibt das nett mit "REPLACE ist eine MySQL-Erweiterung zum SQL-Standard". Mit der ausgiebigen Nutzung solcher Erweiterungen bindet sich der Anwender auf Gedeih und Verderb an ein DBMS.
Doch zurück zu "Merge" mit zwei abschließenden Bemerkungen, die triviale zuerst:
- Auch und gerade beim "Merge" großer Tabellen bringen Indizes für die Spalten im "on"-Teil der Anweisung in der Regel einiges an Performance. Die Zahl der "Locks" lässt sich dadurch signifikant verringern.
- Der Vollständigkeit halber sei zu dem oben verlinkten Artikel noch erwähnt, dass DB2 seit einiger Zeit ein "+" in der Zeile "MERGE" der Konformitätsmatrix hat.
Der Autor des Artikels irrt allerdings in Sachen Standard-Konformität bei Oracle: Die Oracle DB kennt auch heute noch keinen
Basisdatentyp "XML", zumindest nicht so, wie ihn seit "Viper" DB2 implementiert.
ap127