XML versus RDBMS

Es gibt viele Möglichkeiten, Daten zu speichern. Die derzeit (2013) populärsten sind:

• Daten in einem relationalem Datenbankmanagementsystem (RDBMS) zu speichern
• Daten in Form von XML oder JSON speichern, z.B. in einer Datei auf einem Dateisystem
• Sehr einfach strukturierte Daten in einem Key-Value-Store zu speichern
• Daten in einer dokumentenorientierten Datenbank bzw. einer Objektdatenbank zu speichern

Mischen von Speicherarten

Es ist durchaus möglich und oft legitim, verschiedene Speicherarten zu mischen.

Einbettung

Man kann ein XML- oder JSON-Dokument in einer Spalte einer Tabelle in einem RDBMS speichern oder das XML- oder JSON-Dokument als Wert eines Key-Value-Stores und so weiter.

Verbindung von Systemen

Man stellt eine logische Verbindung zwischen zwei Systemen über einen gemeinsamen Schlüssel her. Beispiel: Man hat eine Tabelle in einem RDBMS und es gibt zum Primärschlüssel eine dazu passende (XML-)Datei in einem Dateisystem, deren Name den Primärschlüssel enthält. Das könnte dann etwa so aussehen: Man hat im RDBMS eine Tabelle "Persons" mit folgender Struktur:

ID	Prename	Surname	Birthdate
25	Michael	Kremser	1979/09/20
38	Max	Mustermann	1901/12/24

Im Verzeichnis /opt/persons/pics gibt es für jeden Datensatz eine XML- und eine JPEG-Datei, also 25.xml, 25.jpeg, 38.xml und 38.jpeg.

Überlegungen zur Speicherart

Welche Möglichkeit, Daten zu speichern, die Beste ist, lässt sich nicht pauschal beurteilen und hängt stark vom Anwendungsfall ab, vor allem, wie die Daten strukturiert sind und wie sie verwendet werden. Oftmals sollte man in Betracht ziehen, einer Applikation die Möglichkeit zu geben, den Persistenzlayer auszutauschen und unterschiedliche Implementierungen zur Verfügung stellen, sodass die Anwendung ihre Daten je nach Situation in unterschiedlichen Datenlagern speichern kann.

Man kann jedoch einige Vor- und Nachteile verschiedener Speicherarten objektiv darstellen, um so gegebenfalls die Entscheidung zu erleichtern.

Speicherart	Beschreibung	Vorteile	Nachteile
XML	Offenes Format Daten sind hierarchisch strukturierbar	Leicht zu erlernen Kann leicht mit jedem beliebigem Betrachtungsprogramm/Editor angesehen und gelesen werden (d.h. es ist keine spezielle Software nötig) Unterstützung in allen populären Programmiersprachen Weitgehend plattformunabhängig (Encoding!) Mit XSD diverse Prüfungen der Daten möglich (Validität) XML-Daten können ein Schema (XSD) haben, müssen es aber nicht Mit XSLT in andere Formate transformierbar Unterstützung in vielen Anwendungsprogrammen (z.B. Entwicklungsumgebungen, Browser) Mit XPath können gezielt Daten gesucht werden Kann in einer Datei gespeichert und dann weitergegeben werden Flexibilität der Daten: Kommt ein neues Attribut hinzu, kann dieses einfach bei neuen Knoten dazugeschrieben werden, die alten Knoten haben das Attribut einfach nicht (sofern das Attribut im Schema als optional markiert ist) Attribute sind in Namensbereiche (Namespaces) organisierbar Zugriff auf entfernte Datenquellen über FTP/HTTP und dergleichen einfach durchführbar, daher sind Firewalls auch nur begrenzt ein Problem Unterschiede leicht mittels "diff" oder ähnlichen Programmen ermittelbar (z.Bsp. könnte man die Dateien in einem Codeverwaltungssystem einchecken und die Änderungshistorie verfolgen) Als "Träger" der XML-Daten kann alles dienen, was eine Zeichenfolge aufnehmen kann: Dateien in einem Dateisystem oder bspw. als Anhang in einer E-Mail ("XML-Dateien"), Nachrichten (z.B. Pipes), Sockets (z.B. Übertragung per TCP/IP) oder als Entität in einem anderen System (z.B. Spalte in einer Tabelle in einem RDBMS oder als "Value" in einem Key-Value-Store) Joining/Splitting/Merging: Mehrere XML-Dokumente können zu einem großen zusammengefasst werden, aus einem großen Dokument können aus den einzelnen Knoten mehrere kleinere Dokumente erstellt werden, Schwesterknoten können fusioniert und "defusioniert" werden	Keine eingebauten Transaktionen wie bei RDBMS Simultaner Zugriff auf XML-Dateien kann problematisch sein Integrität der Daten nicht ausreichend sichergestellt Redundantes Vorhalten von Daten zum Zwecke der Datensicherheit schwieriger (muss auf Dateisystemebene durchgeführt werden)
RDBMS	Daten werden von einem RDBMS verwaltet und sind in Tabellen strukturiert	Unterstützung von Transaktionen seitens RDBMS Simultaner Zugriff leicht zu bewältigen Mit SQL steht eine mächtige Abfragesprache zur Verfügung, viele Operationen lassen sich mit wenigen Instruktionen durchführen, die bei textbasierten Dateien sehr aufwändig wären Nebst Tabellen können auch Sichten erzeugt werden Stored Procedures/Functions Integrität der Daten kann über Einschränkungen (Constraints) sichergestellt werden Daten können redundant vorgehalten werden, in dem sie auf mehrere Server verteilt werden, die sich miteinander synchronisieren, somit höhere Datensicherheit Unterschiede in Datenbanken schwieriger fassbar, da Daten binär gespeichert sind; SQL-Abfrage muss Struktur der Daten kennen	RDBMS-Software muss installiert werden (evtl. Plattformabhängigkeit) Dateien können nicht so leicht weitergegeben werden Struktur der Daten in Tabellen "einzementiert": Aufwand bei Änderungen/Ergänzungen etwas höher (es muss explizit ein ALTER TABLE verwendet werden); Möglichkeit von generischem Aufbau, was jedoch das Abfragen, Einfügen, Aktualisieren und Löschen von Daten erschwert Zugriff auf Datenbankserver problematisch, wenn eine Firewall dazwischen ist