bannkreis.de

Beisst die Viper?

IBM stattet ihre im Sommer zu erwartende neue Version von DB2,  aktuell noch durch den schnieken Codenamen "Viper" repräsentiert, mit umfangreichen Funktionen zum Speichern nativer XML-Daten aus und bietet uns zusätzlich, angeblich als erster Hersteller, vollständige XQuery-Unterstützung. Der XML-Datenbank-Fan ruft Hossa!, only what took you so long?
Auf dem Rückweg vom zweieinhalbtägigen IBM DB2 Viper Bootcamp habe ich mich dann doch entschieden, den Titel dieses Posts in der Frageform zu formulieren obwohl ich ihn ursprünglich als kernige Kraftaussage ohne wenn und aber konzipiert hatte. Ich kann nicht behaupten, dass die Zweifel überwiegen, aber sie sind definitiv da. Aber der Reihe nach.

DB2 "kann" XML. Mancher wird argumentieren, dass dies schon lange der Fall ist, gibt es doch bereits seit längerer Zeit Tools wie den XML Extender, welcher XML-Daten auf relationale Tabellen abbildet. Jeder der technisch was auf dem Kasten hat und über dieses Konzept länger als zwei Minuten nachdenkt wird seine wesentlichen Limitationen erkennen, die in der Inflexibilität (das DB-Schema ist auf ein XML-Schema maßgeschneidert), in der durch zahlreiche Relationen fraglichen Performance und der Unabfragbarkeit der XML-Daten - in wahrer XML-Form - liegen.

Eine andere Strategie ist es natürlich, XML einfach als Text in CLOBs abzulegen und es mit den - seit irgendeiner 8er-Version verfügbaren - XML-Parsing-Funktionen abzufragen. Dass es bezüglich Performance keine gute Idee ist, innerhalb einer SQL-Anweisung ein XML-Dokument pro abgefragter Zeile auszuparsen, brauche ich wohl auch niemandem näher erläutern (zumindest niemandem, der es bis hier durch diesen Post geschafft hat :-).

Was macht DB2 also jetzt? Das naheliegende. Es gibt einen neuen Spaltentyp "XML" für normale Tabellen, der in der Lage ist XML-Daten im geparsten Format abzulegen, quasi als DOM-Baumstruktur. Was bedeutet das? XML-Daten müssen nicht geparst werden, wenn sie abgefragt werden, sie liegen quasi sofort in vorgekauter Form vor. Desweiteren gibt es eine neue Query-Engine, welche XQuery-Abfragen versteht und über spezielle Funktionen auf die - im Grunde immernoch relationale Grundstruktur der Datenbank - zugreifen kann um sich ihre XML-Daten zu holen. Das sieht dann in etwa so aus:

XQUERY for $d in db2-fn:xmlcolumn("tabellenname.feldname")
where ...
return $d

Umgekehrt gibt es auch für SQL-Abfragen Funktionen, um entweder aus XML-Spalten spezielle Einzeldaten zu extrahieren, oder den Ergebnis-Satz anhand von XML-Daten zu selektieren. Nicht unwesentlich ist auch die Möglichkeit, Indizes zu definieren, welche spezielle Datenknoten in XML-Spalten indizieren und so für schnelleren Zugriff darauf sorgen. Die zu indizierenden Daten werden als XML Pattern (XPath minus Prädikate) festgelegt.

Reden wir zunächst darüber, was meiner Meinung nach gut an dem Konzept ist. Zunächst einmal finde ich die Idee, eine "relationale XML-Datenbank" zu haben vernünftig. Wenn man richtig darüber nachdenkt, will man auch in einer XML-Datenbank natürlich nicht auf Relationen verzichten. Zwar bewahrt einen die XML-Speicherform davor, Daten die eigenlich zusammen gehören aufgrund ihrer Tiefenstruktur auf verschiedene Tabellen verteilen zu müssen - deren Zusammensetzung man dann mit einer Performance-Penalty bezahlt. Dennoch gibt es natürlich weiterhin unterschiedliche Datensätze, die ich separat ablegen will, und zwischen denen ich dennoch bei Bedarf eine Beziehung aufbauen will.

Konkreter: Eine Rechnung und ihre Rechnungsposition auseinanderzureissen ist wenig sinnvoll. Die Position ist ein Bestandteil der Rechnung, auch wenn sie 1-n mal in ihr auftritt und eigene Datenfelder hat. Daher würde man in einer XML-Datenbank die Rechnung als einzelnes XML-Dokument betrachten, über dessen interne Struktur die Positionen abgebildet werden.

Genauso natürlich aber ist der Kunde ein andersartiger Datensatz als die Rechnung, und natürlich steht er über einen Fremdschlüssel in Beziehung zu seinen Rechnungen. Natürlich will ich daher auch in Abfragen in der Lage sein, beide per Relation zu verbinden und zusammen abfragen zu können. Das betrachtet ist der Ansatz einer puren XML-Datenbank geradezu töricht, zumindest solange wie sie keine (performanten) Relationen in XQuery erlaubt (was DB2 tut).

Daher glaube ich, dass das pure Konzept einfach sehr gut auf reelle Anwendungs-Bedürfnisse passt und echte Probleme löst. Brauche ich noch objekt-relationale Mapper wenn meine Objekte nicht mehr auseinandergerissen werden sondern als XML-Entsprechung in der Datenbank landen? Wohl kaum. Sobald sich diese Möglichkeit also rumgesprochen hat bin ich zuversichtlich dass sie auch benutzt und somit erfolgreich sein wird.

Zu den Bedenken: Wenn sie euch etwas vage erscheinen, dann...sind sie es vielleicht. Da ist zunächst der Eindruck, dass IBM im Detail erkennen lässt, das man sich bzgl. der XML-Funktionen nicht von echten Use-Cases hat leiten lassen. Vielmehr überwiegt das Gefühl, IBM hätte einfach eine Handvoll XML-Funktionen in die grobe Richtung geworfen, wo die Anwender sie mit einiger Wahrscheinlichkeit aufheben würden.

Da ist zunächst die Tatsache, dass die XML-Speicherung ein Spaltentyp für normale relationale Tabellen ist. Tatsächlich werden die XML-Daten zwar intern "ganz woanders" gespeichert als die anderen relationalen Daten der restlichen Tabelle (und unterliegen deshalb auch nicht den Codepage-Restriktionen), aber es wird uns suggeriert, sie gehörten zur Tabelle. Warum eigentlich? Wozu braucht man denn weitere relationalen Spalten wenn man eh XML speichert? Wieso integriert man diese Daten dann nicht direkt mit ins XML? Ich möchte wetten, 95% aller Tabellen die in Zukunft mit XML-Spalten ausgestattet werden, besitzen zusätzlich maximal eine Primärindex-Spalte mit nichtfachlichen Indexwerten, vermutlich meistens ein simples auto-inkrement BIGINT. Die Anzahl von Tabellen mit MEHREREN XML-Spalten, was ja durch das Modell theoretisch möglich ist, dürfte gegen null tendieren.

Stattdessen: Bin nur ich das, oder wäre es nicht irgendwie natürlicher gewesen, wenn es keine XML-SPALTEN gegeben hätte sondern ganze XML-TABELLEN? Also Tabellen, in deren Zeilen nur jeweils ein XML-Dokument gespeichert wird. Man könnte pro Tabelle ein XML Schema festlegen, welches für die Daten dieser Tabelle verbindlich ist, was eine logische Entsprechung zum relationalen Tabellenschema wäre.

Überhaupt XML Schema. Hier hat sich IBM meiner Meinung nach einen kapitalen Bock geleistet. XML Schemas kann man in ein Schema-Repository, welches ab jetzt jede Datenbank besitzt, importieren. Schön. Beim Einfügen von XML-Daten kann ich diese gegen Schemata aus dem Repository validieren. Schön. Ich kann für eine XML-Spalte definieren, dass sie nur validiertes XML annehmen darf. Schön. Aber WARUM ZUM TEUFEL kann ich an eine XML-Spalte kein notwendiges XML Schema binden? 'Scuse me? Heisst das, in meiner XML-Spalte einer Tabelle "Rechnungen" kann sich - laut Tabellendefinition - eine valide Rechnung, aber auch eine valide Kundenbeschreibung, eine valide Kostenstelle oder eine valide Produktbeschreibung befinden, wenn jemand mit der Tabellenadressierung mal nicht so richtig aufpasst? Hauptsache valide? Das kann nicht euer Ernst sein. Natürlich bekomme ich die Situation in meiner Anwendungsentwicklung irgendwie wieder unter Kontrolle, aber das Klassenziel "Effektive Datenrestriktion in der Tabellendefinition" ist deutlich verfehlt, was sich auf Relations-Puristen nicht gerade vertrauensbildend auswirken dürfte.

Kommen wir zum vielleicht größten Problem: Datentypen. Es liegt in der Natur der Sache dass alle Daten in XML zunächst einmal Textdaten sind. Wie werden XML-Daten zu anderen Datentypen? Richtig, indem man im zugehörigen XML Schema einen Datenknoten mit einem speziellen Datentyp, z.B. Integer oder DateTime versieht. Nun ist es ja nicht ganz unerheblich, dass diese Daten, wenn sie in einer XQuery-Abfrage verwendet werden, auch unter ihrem eigentlichen Datentypen verarbeitet werden. Schliesslich ist bekanntlich die Zahl 3 kleiner als die Zahl 29, während der Text "29" aufgrund der String-Vergleichslogik kleiner ist als der Text "3". Daher liegt es nahe von einer Datenbank zu erwarten, dass sie die XML Schema Datentypen berücksichtigt. Tut dies DB2?

Die Frage, wie sie zwangsläufig irgendwann im Bootcamp gestellt wurde, hätte die Referenten nicht kalter erwischen können. Die einzige Möglichkeit, XML-Daten zu "enttexten", die ihnen bekannt war, war die Erschaffung eines Indexes auf das problematische Feld, dem man somit auch einen Datentypen zuweisen konnte. Jedoch keinen XML Schema Datentypen sondern einen SQL-Datentypen! Das wurde, wie man sich unschwer vorstellen kann, mit einem Raunen seitens der Audienz quittiert. Da hat das Ding nicht nur in XQuery einen SQL-Datentypen (der eventuell inkompatibel mit dem XML Schema Datentypen ist. Verwenden beide dieselbe Syntax für Datumsliterale?), ich muss auch noch für jedes Nicht-Text-Feld im XML einen Index erstellen, einzig und allein damit die Datenbank den Typen begreift.

Die Geschichte hängt noch etwas in der Luft. Bislang ist es mir nicht eindeutig gelungen zu beweisen, dass DB2 keine Schema-Datentypen in XQuery berücksichtigt, bzw. es zu falsifizieren. Erste Tests in diese Richtung machen jedoch nicht viel Mut.

Fazit: DB2 Viper zeigt den zu gehenden Weg deutlich vor, und man muss sich wirklich fragen, warum dieser Weg nicht schon viel früher von einem der großen Anbieter gegangen worden ist (zu resistente RDBMS-Freaks? Vielleicht, das Thema hatten wir ja schonmal. Im Bootcamp schien es jedenfalls tatsächlich DB2-Admins zu geben, denen man ernsthaft die Konzepte um XML noch erklären musste. Haben wir wirklich 2006?). Im Detail aber gibt es mal wieder ärgerliche Unbedachtheiten, die den produktiven Einsatz hoffentlich nicht blockieren. Es wäre wirklich schade, wenn das bescheidene Momentum, welches sich jetzt wieder um das XML-Datenbank-Thema bildet, deswegen wieder ungenutzt abebbt.
Kommentare:

comment von Oliver Samstag 02. September 2006, 14:46

Viper beachtet die im XML Schema angegebenen Datentypen bei XQuery, zumindest dann wenn das Dokument bei seinem INSERT durch die XMLVALIDATE-Funktion gejagt wurde. Damit ist das größte angesprochene Problem nichtig. Nur die Arbeit mit Namespaces in XML Schema, XQuery, XPath ist ein unglaublicher Krampf. Empfehlung: Global darauf verzichten falls nicht unbedingt notwendig. Rant folgt.

comment von Guido Jansen Samstag 02. September 2006, 14:46

Also ich kenne den grossen Reiz möglicher XML-Datenbanken nur aus genau Deinem Blog (kann ihn aber nachvollziehen) und kann mich immerhin damit brüsten bis auf XQuery alle Fachbegriffe schonmal gehört zu haben (aber auch nicht mehr!!), und in der Tat ist mir auch beim Anlesen des Themas der Gedanke gekommen, dass die Lösung doch in einer Table pro XML-Dokument liegen muss, welches dann Verknüpfungen und Attribute gesondert abspeichern kann, also quasi ein "voll-integriertes Parallel-Dasein" mit der sonstigen DB eingeht. Aber was sonstige Kommentare angeht muss ich passen und hoffe, dass Deine Wünsche da in Erfüllung gehen und dieses Blog auch fachlich ne Menge Leser findet!

Bitte geben Sie hier Ihren Kommentar ein:

Verwende Markdown Syntax

Autor

About

Last comments

  • Oliver:
    Als Antwort auf "Anonym" vom 27. Dezember 2015 (..
  • anonym:
    Habbo als abzocke zu deklarieren finde ich schon..
  • anonym:
    Wenn du es dir leisten kannst und es dich glückl..
  • Jebote:
    ja sicher kommen alle auf diesen 5 jahre alten a..
  • Micha:
    @Ingo, na klar. Alles legitim und voll ok ;-) Mu..

Really currently consuming

Links

  • Mehr Whisky
  • Ich@last.fm
  • Ich@Twitter
  • Dina
  • Julia
  • Der Meister (nebst Frau Meister)
  • Rockender Webworker
  • Irgendwas mit Fischen