Naiv nativ

XML-basierte Applikationen verlangen wie andere nach immer effektiveren Lösungen zur Speicherung von Daten im XML-Format. Je nach Anwendungsfall kommen hier native XML-Datenbanken oder herkömmliche relationale in Verbindung mit Mapping-Tools in Frage.

In Pocket speichern vorlesen Druckansicht 48 Kommentare lesen
Lesezeit: 3 Min.
Von
  • Ludwig Mittermeier

XML als Datenaustauschformat hat mittlerweile große Verbreitung erlangt. Bei der Verwendung von XML kann man auf Parser und Tools zurückgreifen, die für zahlreiche Betriebssysteme und fast jede Programmiersprache verfügbar sind. Einhergehend mit der zunehmenden Verbreitung von XML zum Datenaustausch zeichnet sich die Tendenz ab, Daten direkt als XML zu speichern. Sei es der Produktkatalog einer neu entwickelten Verkaufsplattform oder die temporäre Speicherung des XML-Datenaustausches zwischen zwei Firmen, man spart sich den Aufwand für die Umwandlung von proprietären Datenformaten nach XML und umgekehrt.

Der vorliegende Artikel soll über Lösungen zur Speicherung von XML informieren sowie darlegen, welche Vorteile, Schwierigkeiten und Stolperfallen die jeweiligen Produktkategorien und die Speicherung von XML im Allgemeinen bereiten. Darüber hinaus soll es darum gehen, welche Kriterien bei der Auswahl eines Produkts zu berücksichtigen sind.

Vor allem bei Konfigurationsdaten begegnet einem XML zumeist in Form relativ einfacher Dateien. Geht es jedoch über das simple Lesen solcher Konfigurationsdaten hinaus, trifft man auf eine Reihe von Anforderungen, die die Art der XML-Speicherung erfüllen sollte, die weit über das, was Dateien können, hinausgehen. Erfordert die Anwendung beispielsweise nach Suchoperationen über mehrere XML-Dokumente hinweg update-Operationen, effizientes Caching oder den Umgang mit gleichzeitigen Zugriffen, ist eine leistungsfähigere Lösung notwendig.

In manchen Anwendungsfällen kann es notwendig sein, beliebig strukturierte XML-Dokumente zu speichern, ohne vorher Konfigurationseinstellungen (siehe Mapping-Informationen weiter unten) vorzunehmen. Entspricht ein zu speicherndes Dokument nicht einem bestimmten Schema oder einer DTD (Dokumenttyp-Definition), sollte dessen Speicherung automatisch abgelehnt werden. Gespeicherte XML-Daten muss man schließlich wieder lesen können - in Form ganzer Dokumente, von Dokumentteilen, einzelner Elemente oder sogar Attributwerte. Hierfür ist eine geeignete Anfragesprache notwendig.

Das Ergebnis von Anfragen sollte im Idealfall nicht nur ein einzelnes gespeichertes Dokument oder Teile daraus sein, sondern aus Teilen mehrerer gespeicherter Dokumente zusammengesetzt sein können. Ob sich diese Datenzugriffsoperationen innerhalb der XML-Sprachfamilie oder anderweitig (beispielsweise per SQL-Anweisungen) durchführen lassen, kann ebenfalls ein Anforderungskriterium darstellen.

Viele Publikationen zum Thema XML und Persistenz teilen XML-Dokumente in zwei Kategorien ein: dokumenten- und datenzentriert. Dokumentenzentriert sind sie, wenn sie in der Regel für die Verarbeitung/Auswertung durch Menschen bestimmt sind, etwa manuell verfasste (Text-)Dokumente, die ganz oder in Teilen beispielsweise für Suchmaschinen, Websites, Zeitschriftenartikel oder Bücher Verwendung finden können. Sie sind gekennzeichnet durch eine unregelmäßige, wenig vorhersehbare Struktur mit relativ geringer Schachtelungstiefe.

Datenzentriert hingegen sind solche XML-Dokumente, die zumeist zum maschinellen Datenaustausch verwendet werden, wie Daten zu Bestellvorgängen. Typischerweise zeichnet sich datenzentriertes XML durch eine festgelegte, exakt definierte und gleichbleibende Struktur aus.

In der Printausgabe finden Sie mehr zu XML in relationalen und so genannten nativen Datenbanken; außerdem zwei weitere Artikel: zu Oracle 9i und dessen XML-Erweiterungen sowie einen Praxistipp, wie man XML in MYSQL-Tabellen transformiert. (hb)