Über unsMediaKontaktImpressum
Dr. Christoph Gaukel 07. Juni 2016

BaseX, eine XML-Datenbank

NoSQL-Datenbanken sind in aller Munde. Für relationale Datenbanken, die seit den 1970er Jahren auf dem Markt sind und seit Jahrzehnten den Standard repräsentieren, sind echte Konkurrenten aufgetaucht. Dieser Artikel stellt eine solche Datenbank vor.

BaseX ist eine XML-Datenbank, die man im Blick haben sollte. Elegant, einfach und lizenzfrei, dazu noch schnell und reif für den professionellen Einsatz. Dieser Artikel ist ein Streifzug, der vielleicht Appetit auf mehr macht.

Historischer Rückblick

20 Jahre XML sind Anlass für eine Bilanzierung. Der XML-Standard wurde als W3C Working Draft 1996 veröffentlicht, vier Jahre nachdem HTML, der geistige Vater, die Bühne betreten hatte. Darauf folgten im Jahr 1999 XPath und XSLT als zwei zeitgleich veröffentlichte Standards. Wer heute in die Bücher schaut, die um das Jahr 2000 geschrieben wurden (z. B. Michael Kays Buch über XSLT aus dem Jahr 2000), der wundert sich über den grenzenlosen Optimismus. XML, das schien das Tor zu einer neuen Dimension der Datenverarbeitung. Der perfekte Kompromiss, ein Standard, von Menschen intuitiv zu erfassen, von Maschinen effektiv zu verarbeiten. Inhalt und Struktur verschmelzen zu einer Einheit. Auch heute noch verblüfft die Eleganz des Ansatzes:

<KundenBestand>
  ...
  <Kunde Nr="456789">
    <Name>
      <Zuname>Müller</Zuname>
      <Vorname>Peter</Vorname>
    </Name>
    <GebDatum>1996-11-14</GebDatum>
    <Adressen>
      <MeldeAnschrift>
    <Strasse>Hauptstr.</Strasse>
    <HausNr>12</HausNr>
    <PLZ>12345</PLZ>
    <Ort>Gibtsnich</Ort>
      </MeldeAnschrift>
      <NebenWohnsitz>
    <Strasse>Fliederweg</Strasse>
    <HausNr>2</HausNr>
    <PLZ>23456</PLZ>
    <Ort>Schoenists</Ort>
      </NebenWohnsitz>
      <LieferAdresse>
    <Strasse>Industriestr.</Strasse>
    <HausNr>32</HausNr>
    <PLZ>12345</PLZ>
    <Ort>Gibtsnich</Ort>
      </LieferAdresse>
    </Adressen>
  </Kunde>
  ...
</KundenBestand>     

XPath-Ausdrücke sind ebenfalls intuitiv. Nehmen wir an, die obigen Kundendaten stehen in einer Datei MeineKunden.xml. Dann sieht der Zugriff auf die Postleitzahl der Meldeanschrift des Kunden 456789 wie folgt aus:

doc("./MeineKunden.xml")/KundenBestand/Kunde[@Nr="456789"]/Adressen/MeldeAnschrift/PLZ

Warum wird dieser Standard zwar massiv im Datenaustausch eingesetzt, kaum aber in der Datenhaltung? Weil es bisweilen viele Jahre dauert, zu einem überzeugenden Standard auch überzeugende Tools auf den Markt zu bringen und zu etablieren. In den Jahren nach 1999 bestand das Team aus XML, XPath und XSLT. XML-Daten wurden als statische Dateien abgelegt oder in relationalen Datenbanken persistiert. Bei der Weiterreichung der Daten aus einem Haushalt an den nächsten war zuerst eine Aufbereitung in XML notwendig, was relativ einfach ist. Anschließend aber eine aufwändige Überführung der XML-Daten in ein relationales Modell. XSLT kann Daten aufbereiten, persistiert sie aber nicht in eine Datenbank. Seit 2005 gibt es mit XQuery, neben den bereits genannten, einen weiteren XML-Standard, den ich für einen großen Wurf halte. XQuery füllt die Lücke, es ist in der Lage, XML-Daten in Datenbanken zu schreiben. Wie XSLT baut XQuery auf XPath auf, jeder XPath-Ausdruck ist automatisch auch ein gültiges XQuery-Skript. XQuery ist aber gleichzeitig eine funktionale Skript-Sprache, in der man umfangreiche Programme schreiben kann.

Was ist eine XML-Datenbank?

Eine XML-Datenbank speichert Daten im XML-Format – um genau zu sein: XML-Dokumente. Die Zugriffe auf die Daten erfolgen durch XQuery. Das Abspeichern eines Files ist verblüffend einfach. XML-Dokumente werden eingelesen und indiziert abgelegt. Art und Umfang der Indizierung können, müssen aber nicht, detailliert festgelegt werden. Die Indizierung erfolgt nach Attributen, nach Texten und/oder für eine Volltextsuche. Um z. B. die Datei MeineKunden.xml als Datenbank Kunden zu persistieren, genügt das folgende XQuery-Skript:

db:create("Kunden", "./MeineKunden.xml")

oder für den Fall, dass alle Attribute (in unserem Fall die Kundennummer) und zusätzlich nur die Textinhalte der Elemente <Zuname> als Index benötigt werden:

db:create("Kunden", "./Kunden.xml", (), map{"updindex": true(), "textinclude": "Zuname"})

updindex wird gesetzt, damit die Indizes bei jedem schreibenden Zugriff automatisch aktualisiert werden. Mehr dazu später.

Um eine Vorstellung für die Performance einer XML-Datenbank zu entwickeln, habe ich einen Kundenbestand mit etwas mehr als 300.000 Kunden nach dem obigen Vorbild als Datei erstellt und diese dann als XML-Datenbank persistiert. Im ersten Fall, bei dem alle Textfelder indiziert werden, benötigte mein (relativ schwachbrüstiger) Laptop knapp 36 sec. Im zweiten Fall, bei dem die Indizierung optimiert war, waren es noch 25 sec. Das Resultat war jeweils eine Datenbank mit ca. 100 MByte Größe und ca. 5,4 Mio. Knoten. Wir halten also fest: Die Persistierung von XML-Daten in XML-Datenbanken ist einfach und sehr performant.

Lesende Zugriffe auf XML-Datenbanken

Nun greifen wir auf die eben erzeugte Datenbank zu und lesen die Daten eines unserer ca. 300.000 Kunden:

doc("Kunden")/KundenBestand/Kunde[@Nr="456789"]

Auffallend ist bereits, dass die Syntax der Zugriffe auf XML-Files und auf XML-Datenbanken fast identisch ist. Ein Hinweis darauf, dass XQuery mit XML-Dokumenten arbeitet. Die spezifische Form der physikalischen Ablage steht dabei im Hintergrund. Die Antwortzeit war 20 ms. Als nächstes wollen wir wissen, wie viele Kunden mit dem Zunamen Müller wir im Kundenbestand haben:

doc("Kunden")/KundenBestand/Kunde[Name/Zuname="Müller"] => count()

oder mit einem direkt den Index nutzenden Zugriff:

db:text("Kunden", "Müller")/parent::Zuname => count()

Im ersten Fall benötigt der Zugriff 40 ms, im zweiten Fall 31 ms. Beide liefern die Information, dass sich 2.148 Müllers im Bestand befinden. Der geringe Performance-Unterschied zwischen der Nutzung des Indexes und dem indexfreien Zugriff zeigt, dass der XQuery-Interpreter den Zugriff optimiert und auch dann den Index nutzt, wenn ein ganz normaler XPath-Ausdruck (ohne Index) verwendet wird. Wir werten ein Element aus, für das kein Index existiert:

doc("Kunden")/KundenBestand/Kunde[Name/Vorname="Peter"] => count()

Nach 1,5 sec. erfahren wir, dass 726 unserer Kunden mit Vornamen Peter heißen. Auch diese Antwortzeit ist beachtlich. Immerhin musste für über 300.000 Kundensätze geprüft werden, ob der Vorname übereinstimmt. Den Eintrag der Vornamen in den Textindex hatten wir ja ausdrücklich nicht gewünscht.

Ihre ganze Stärke spielen XML-Datenbanken dann aus, wenn nicht Einzelfelder, sondern ganze Datenstrukturen aus der Datenbank gelesen werden. Während bei SQL-Datenbanken die Normalform eine Aufteilung zusammengehöriger Daten in verschiedene Tabellen fordert, werden XML-Dokumente in der gelieferten Struktur abgelegt. Auf jede Strukturebene kann direkt zugegriffen werden. Während das Beispiel mit db:text auf der untersten Ebene (dem Textknoten) aufsetzt und sich dann zu der höheren Ebene bewegt, wird i. d. R. die umgekehrte Richtung verwendet, vom Dokument zum Kundenbestand zum Kunden zum Namen zum Zunamen. Das entspricht der menschlichen Herangehensweise an strukturierte Daten. Die Datenbank liefert die Daten immer als Referenzen von Knoten, die dann weitergereicht oder zu neuen Datenstrukturen zusammengefügt werden. An jedem Knoten hängt der ganze Kontext. Es ist ohne weiteres möglich, irgendeinen Knoten eines Dokuments im Zugriff zu haben, und damit das ganze Dokument zu bearbeiten:

let $kunde := doc("Kunden")/KundenBestand/Kunde[@Nr="456789"]
return
  $kunde/parent::KundenBestand/Kunde[Name/Zuname="Meier"] => count()

Eine etwas seltsame aber zulässige Methode, vom Kunden mit der Kundennummer 456789 ausgehend, zu ermitteln, dass sich 182 Personen mit dem Zunamen Meier im Kundenbestand befinden.

Als letztes werfen wir noch einen kurzen Blick auf die Volltextsuche (XQuery and XPath Full Text 1.0 von 2011):

let $kunden := doc("Kunden")/KundenBestand/Kunde[Name/Zuname contains text "Baumgärtner" using fuzzy]
return
  (
    count($kunden),
    distinct-values($kunden/Name/Zuname)
  )

Wir suchen alle Kunden, deren Zuname den Text Baumgärtner oder so ähnlich (die fuzzy-Option ist eine proprietäre Erweiterung der BaseX-Datenbank) enthält. Wir geben die Anzahl der Kunden und die verschiedenen Namensvarianten aus:

151
Baumgarten
Baumgärtner
Baumgartner
Baumgartner-Welde
Baumgartner in Albanello
Baumgärtner-Schuster
Baumgärtner-Jaja
Baumgärtel
Bremgärtner
Brehmer-Baumgartner
Grom-Baumgarten

Es gibt im Kundenbestand also 151 solche Kunden und 11 verschiedene Varianten des Zunamens. Die Abfrage braucht 3 sec. Wir können den Kundenbestand aber auch mit einem Index für die Volltextsuche versehen:

db:create(
  "Kunden",
  "./Kunden.xml",
  (),
  map{
    "updindex": true(),
    "textinclude": "Zuname",
    "ftindex": true(),
    "tokeninclude": "Zuname"
  }
)

Dann dauert das Laden des Kundenbestands etwas länger (37 sec.). Die Ausführung des obigen XQuery-Skriptes mit den Varianten der Baumgärtners auf einem indizierten Bestand benötigt aber nur noch 60 ms.

Schreibende Zugriffe auf XML-Datenbanken

Die XQuery Update Facility 1.0 wurde ebenfalls 2011 veröffentlicht. Mit ihr wurden die schreibenden Zugriffe auf XML-Dokumente vereinheitlicht. Zuvor hatten die verschiedenen XML-Datenbanken jeweils ihre eigene proprietäre Syntax verwendet. Wir fügen eine weitere Kundin in unseren Kundenbestand ein:

let $kunde :=
    <Kunde Nr="876543">
      <Name>
        <Zuname>Müller</Zuname>
        <Vorname>Petra</Vorname>
      </Name>
      <GebDatum>1998-02-10</GebDatum>
      <Adressen>
     <MeldeAnschrift>
      <Strasse>Hauptstr.</Strasse>
      <HausNr>12</HausNr>
      <PLZ>12345</PLZ>
      <Ort>Gibtsnich</Ort>
     </MeldeAnschrift>
      </Adressen>
    </Kunde>
return
  insert node $kunde into doc("Kunden")/KundenBestand

Das XQuery Skript benötigt 35 ms.

Wir ändern die Kundennummer des Kunden 456789:

replace value of node db:attribute("Kunden", "456789", "Nr") with "987654"

Die Ausführung dauert 190 ms.

Wir löschen den Kunden mit der Kundennummer 1234:

delete node doc("Kunden")/KundenBestand/Kunde[@Nr="1234"]

Dauer: 700 ms.

Wir löschen alle 2.149 Müllers aus dem Bestand:

delete nodes doc("Kunden")/KundenBestand/Kunde[Name/Zuname="Müller"]

Dieser Vorgang benötigt 49 sec. Das ist aufwändiger als das Einlesen und Indizieren des ganzen Kundenbestands! Das müssen wir uns etwas genauer ansehen. Durch das Setzen der Option updindex haben wir die Datenbank dazu gebracht, sich ähnlich wie eine SQL-Datenbank zu verhalten und nach jedem Schreiben die Indizes zu aktualisieren. Für massenhafte Updates ist das aber ineffektiv. Hier wäre es besser gewesen, die Option updindex nicht zu setzen und die Datenbank nach dem Schreiben zu optimieren:

( delete nodes doc("Kunden")/KundenBestand/Kunde[Name/Zuname="Müller"],
  db:optimize("Kunden") )

Das dauert knapp 7 sec. Davon entfallen nur 800 ms auf das Löschen, der überwiegende Teil der Zeit wird für das Optimieren benötigt.

Während das Einfügen, Ändern und Löschen von Daten syntaktisch einfach ist, ist die Performance deutlich anders und z. T. schlechter als bei SQL-Datenbanken. Da die Daten, wie oben beschrieben, alle miteinander zusammenhängen und hierarchisch angeordnet sind, sind Updates relativ aufwändige Operationen. Bei der Frage der Performance von schreibenden Zugriffen zeigt sich: Auch bei XML-Datenbanken ist nicht alles einfach! Vor allem zeigen sie eine wesentlich andere Performance-Charakteristik als relationale Datenbanken.

Die gute Nachricht ist, dass sehr große Transaktionen möglich sind und sehr effektiv abgearbeitet werden (denn der eben beobachtete Overhead für das Optimieren tritt nur einmal pro Transaktion auf). Jedes XQuery-Skript (mit evtl. vielen tausenden von Updates) wird in einer Transaktion verarbeitet. Alle schreibenden Zugriffe werden als Stapel gesammelt (pending update list) und am Ende in die Datentabellen der XML-Dokumente eingetragen, so dass kein dirty read möglich ist. Halb abgearbeitete XQuery-Skripte sind ausgeschlossen, es gibt auch keine Pendants zu den SQL-Befehlen commit und rollback. Für XQuery gilt: ganz oder gar nicht! Schreibende Zugriffe auf XML-Datenbanken sind also performant, wenn sie dem Profil einer klassischen Batchverarbeitung entsprechen. Insbesondere dann, wenn die geschriebene Datenmenge relativ groß gegenüber dem vorhandenen Datenvolumen ist.

Wer sehr viele unabhängige und kleine Updates auf einen großen und unteilbaren Datenbestand durchführen muss und dafür eine gute Performance braucht, sollte sich gut überlegen, ob er eine XML-Datenbank einsetzt.

Wer in die Verlegenheit kommt, auf eine XML-Datenbank gesetzt zu haben und dann doch auf eine SQL-Datenbank zugreifen muss, kann auch das in seinen XQuery-Skripten tun. BaseX z. B. ist in Java geschrieben und besitzt ein Modul, das über JDBC auf SQL-Server zugreifen kann. Die Daten werden dann in XML eingepackt und stehen für das XQuery-Skript zur Verfügung.

XQuery als Programmiersprache

XQuery ist eine voll typisierte funktionale Programmiersprache. Als solche ist sie elegant, aber für einen Programmierer, der nur imperative Sprachen kennt, durchaus gewöhnungsbedürftig. Umfangreiche Programme in XQuery zu schreiben, erfordert intellektuelle Disziplin. Dafür erhält man als Resultat einen extrem kompakten Code, in den sich kaum Flüchtigkeitsfehler einschmuggeln lassen. Andererseits sind sehr unterschiedliche Architekturschnitte möglich. Man kann XQuery durchaus so benutzen wie SQL. Nur die Zugriffe auf die Daten schreibt man mit XQuery, alles andere mit Java, python oder C#.

Wenn man sich dafür entschieden hat, etwas mehr als das absolut Notwendige mit XQuery zu kodieren, dann stehen mit Maps, Arrays oder Sequences moderne Elemente zur Strukturierung von Daten zur Verfügung. Auch die Signatur einer Funktion lässt sich exakt beschreiben:

declare %public function mein-modul:finde-kunden(
  $zuname  as xs:string,
  $plz     as xs:string
) as element(Kunde)* {
...
};

Diese Funktion finde-kunden ist öffentlich und wird mit zwei Strings als Parameter aufgerufen. Sie liefert eine Sequenz von Elementen <Kunde> die auch leer sein darf. Sollte bei der Programmierung ein Fehler aufgetreten sein, so dass sich im Resultat der Funktion z. B. ein Element <Zuname> befindet, wird bei der Ausführung ein Fehler geworfen. Die Fehlerbehandlung entspricht der einer modernen Programmiersprache mit einer try/catch-Struktur. Die natürliche Einheit einer funktionalen Sprache sind Funktionen, die man in Modulen ablegen kann. Module werden dann einem Namespace zugeordnet:

module namespace mein-modul="MeinModul.xqm";

Hier wird das XQuery-Modul MeinModul.xqm dem Namespace mein-modul zugeordnet. Anschließend werden die in MeinModul.xqm enthaltenen Funktionen jeweils mit Namespace aufgerufen:

let $kunden := mein-modul:finde-kunden("Klein", "12345")

Zu BaseX gehört eine beträchtliche Anzahl von Erweiterungen, die bereits mit festen Namespaces eingebunden sind. Daneben gibt es zusätzlich die Möglichkeit, weitere Java-Klassen unter jeweils eigenen Namespaces einzubinden und ihre Methoden aus XQuery heraus aufzurufen. Auf diese Weise lassen sich die schon sehr mächtigen Bibliotheken mit vorhandenen Funktionen fast beliebig erweitern.

XML und Json

Über JavaScript hat sich Json als prägnante Alternative zu XML etabliert. Ein denkbares Szenario für eine XML-Datenbank ist daher ein HTTP-Server, der über REST-Services Daten im Json-Format liefert. Auch das ist mit XML-Datenbanken möglich. XML und Json sind relativ nah verwandt, so dass es effektive Möglichkeiten gibt, XML in Json umzuwandeln und über einen REST-Zugriff auszuliefern. Wenn Sie Daten in XML erhalten, aber in Json benötigen, dann stellt XQuery eine effektive Alternative zu JavaScript dar. Wer einmal mit XPath gearbeitet hat, um XML-Daten zu verarbeiten, der wird schwerlich darauf verzichten wollen.

Migration und Backup

Ein wesentlicher Vorteil von XML-Datenbanken ist, dass die Daten als gültige XML-Dokumente abgelegt werden. So einfach wie sie eingelesen werden, so einfach werden sie auch wieder exportiert. Die Daten, die eine XML-Datenbank ausspuckt, können in aller Regel von einer anderen XML-Datenbank ohne großen Aufwand persistiert werden. Wem also das Risiko zu groß erscheint, im jetzigen Stadium auf ein relativ unbekanntes Produkt zu setzen, der sollte diesen Aspekt berücksichtigen.

Das gilt auch für Backups. Bei XML-Datenbanken ist es so gut wie ausgeschlossen, dass ein Backup nicht mehr zu verwenden ist. Backups sind komprimierte XML-Dokumente. Bei der Kompression veschwindet der Overhead der wiederkehrenden Markup-Elemente fast vollständig. Ich denke, es gibt im ganzen Umfeld der Datenbanken keine Alternative, die so gut sicherstellt, dass aus einem System, das seit 10 Jahren kein Entwickler mehr angefasst hat und dessen Details kein erreichbarer lebender Mensch mehr kennt, wenigstens die Daten gerettet und in einen anderen Datenhaushalt überführt werden können.

Datenqualität

Einem echten Datenbankadministrator wird die große Freiheit einer XML-Datenbank eher Sorgen als Freude bereiten. Alles, was syntaktisch korrektes XML ist, lässt sich fast beliebig in ein XML-Dokument einfügen. Wer hier regulierend eingreifen möchte, verwendet Schemas. Hier stehen mehrere Standards in Konkurrenz (W3C XML Schema (2001), Relax NG (2001), DTD (1998)). XML-Datenbanken stellen Module zur Verfügung, mit denen XML-Dokumente oder auch XML-Fragmente gegen ein Schema validiert werden.

XQuery und XSLT

XQuery besitzt effektive Sprachelemente, um Datentransformationen durchzuführen (z. B. copy - modify - return). Wer mit XQuery vertraut ist, wird kaum das Bedürfnis verspüren, XSLT einzusetzen. Allerdings sind in vielen Anwendungen umfangreiche XSLT-Skripte vorhanden, auch kann die Expertise der Mitarbeiter dazu führen, dass XSLT dauerhaft im Einsatz bleibt. I. d. R. liest XSLT ein vorhandenes XML-Dokument und erzeugt ein neues XML-Dokument. XSLT-Transformationen lassen sich innerhalb eines XQuery-Skriptes ausführen, so dass sich das Vorhandene ganz natürlich in das neue Umfeld einfügen lässt.

XML-Datenbanken und ihre Anforderungen an die Hardware

XML-Datenbanken legen ihre Daten im Filesystem des Servers ab. Die Mindestanforderungen an die Hardware sind denkbar gering. Nur wer riesige Datenmengen in eine Transaktion packt, benötigt einen entsprechenden Arbeitsspeicher, um sie zwischenzulagern. In kritischen Fällen kann aber auf temporäre Dateien zurückgegriffen werden um die Hardware zu entlasten. I. d. R. wird weniger als ein GByte Arbeitsspeicher benötigt.

Was ist BaseX?

BaseX ist eine XML-Datenbank (und damit eine NoSQL-Datenbank), die seit 2005 an der Universität Konstanz entwickelt wird. Sie ist plattformunabhängig und steht unter der freien BSD-Lizenz. Sie ist in Java geschrieben und implementiert den vollständigen Standard XQuery 3.1. Sie unterstützt ein breites Spektrum von APIs: REST, WebDAV, XML:DB, XQJ; Java, C#, Perl, PHP, Python und andere. Damit steht sie in einer Reihe mit der Enterprise NoSQL-Datenbank von Marklogic (Marklogic Server) oder eXist-db, der anderen Open Source (LGPL)-XML-Datenbank. BaseX besitzt ein graphisches User Interface um XQuery-Skripte zu entwickeln, aber auch um XML-Daten zu visualisieren. BaseX kann in drei Szenarien betrieben werden. Als Standalone mit exklusivem Zugriff durch einen Anwender. In dieser Variante ist BaseX extrem leichtgewichtig. In einer Client-Server-Architektur mit differenzierten Benutzerrechten oder als HTTP-Anwendung, die zusätzlich Zugriffe per REST ermöglicht. BaseX erlaubt es, einzelne XML-Dokumente mit bis zu 4 Milliarden Knoten abzulegen, das entspricht i. d. R. einer Dateigröße von weit mehr als 10 GByte. Unser Kundenbestand mit seinen ca. 300.000 Kunden belegt etwas mehr als ein Promille der maximalen Dokumentgröße. Es ist auch möglich, andere Formate als Binärdaten abzulegen.

Neben dem Produkt BaseX gibt es auch eine Firma (BaseX GmbH). Es handelt sich um eine Ausgründung der Univerität Konstanz, die Consulting, Training, aber auch Anwendungsentwicklung anbietet. Das Produkt BaseX ist lizenzfrei (auch im kommerziellen Einsatz). Weiterentwicklungen für spezifische Anforderungen werden als gesponsorte Entwicklungen durchgeführt, die dann in das Produkt integriert werden und damit allen Anwendern zur Verfügung stehen. Im Rahmen des unten kurz beschriebenen Projektes wurde so das Modul strings entwickelt, mit dem die Levenshtein-Distanz bzw. phonetische Übereinstimmung von Zeichenketten ermittelt wird.

Erfahrungen mit BaseX

Für ein Rechenzentrum im öffentlich-rechtlichen Umfeld wurde in den Jahren 2015 und 2016 eine Anwendung realisiert, mit der die Daten von ca. 7 Mio. Personen in einer BaseX-Datenbank abgelegt werden. Die Anwendung ist an den bundeseinheitlichen Datenaustausch nach OSCI-XMeld angebunden. Dabei kommen die Vorteile einer XML-Datenbank voll zur Geltung. Die Struktur des Datenhaushalts entspricht in hohem Maße der Struktur der Schnittstelle. Die Daten werden pro Kommune geliefert und auch pro Kommune abgelegt. Der zentrale Datenhaushalt besteht damit aus mehreren tausend Dokumenten bzw. Datenbanken und ist skalierbar. Die Anwendung ist in hohem Maß performant und stabil.

Fazit

Ich persönlich habe es zu keinem Zeitpunkt bereut, für eine unternehmenskritische Anwendung auf moderne XML-Technologie gesetzt zu haben. Der Entscheidungsprozess gestaltete sich schwierig, da es viel Mut kostet, Neuland zu betreten. XML-Technologie entspricht derzeit nicht dem State of the Art. Obwohl NoSQL-Datenbanken in aller Munde sind, werden sie selten im Zusammenhang mit XML gesehen. Dabei bilden die Standards XML, XPath und XQuery ein leistungsstarkes Team, das in modernen XML-Datenbanken überzeugend zusammenspielt.

Heutige XML-Datenbanken sind Chamäleons, die sich in sehr unterschiedliche Umgebungen erfolgreich einfügen können. Wesentliche Pluspunkte sind die eleganten Möglichkeiten der Datenmodelierung und -präsentation. Wer seinem Auftraggeber die Daten als XML präsentieren kann, hat deutliche Vorteile gegenüber einem Entity-Relationship-Modell. XQuery ist auch gut geeignet, XML-Daten in XHTML umzuwandeln und passt damit hervorragend zu Rapid Prototyping.

XML hat nach dem Hype um das Jahr 2000 und der Ernüchterung der letzten Jahre eine zweite Chance verdient. Die modernen Tools sind überzeugend und können gegenüber dem aktuellen Standard mit XML-Schnittstellen und relationaler Persistierung wesentiche Produktivitätsgewinne erzielen. Jede gut entworfene Schnittstelle enthält bereits mehr als das halbe Datenmodell, allerdings nur, wenn man eine XML-Datenbank einsetzt.

Weiterführende Quellen
  1. BaseX: baseX.org
  2. XQuery Update (BaseX-Dokumentation): Update
  3. BaseX-Liste der Module (sie enthalten Funktionen, die z.T. nicht im Standard XQuery enthalten sind): Module Library
  4. W3C Standard: Extensible Markup Language (XML) 1.1 (Second Edition)
  5. W3C Standard: XML Path Language (XPath) 2.0 (Second Edition)
  6. W3C Standard: XQuery 3.1: An XML Query Language
  7. W3C Standard: XSL Transformations (XSLT) Version 2.0
  8. P. Walmsley, 2015: XQuery, 2nd Edition, O'Reilly Media
  9. E. Siegel, A. Retter, 2014: eXist, A NoSQL Document Database and Application Platform, O'Reilly Media

Autor

Dr. Christoph Gaukel

Dr. Christoph Gaukel ist selbständiger Software-Berater. Er ist promovierter theoretischer Physiker und versucht, komplexe abstrakte Sachverhalte in einfachen, eleganten und nachvollziehbaren Modellen abzubilden.
>> Weiterlesen
botMessage_toctoc_comments_9210