XML als Datenspeicher verwenden [geschlossen]

Ich habe über das XML-Format und das folgende Zitat nachgedacht:

„XML ist keine Datenbank. Es sollte nie eine Datenbank sein. Es wird niemals eine Datenbank sein. Relationale Datenbanken sind bewährte Technologien mit mehr als 20 Jahren Implementierungserfahrung. Sie sind solide, stabile und nützliche Produkte. Sie gehen nicht weg. XML ist eine sehr nützliche Technologie zum Verschieben von Daten zwischen verschiedenen Datenbanken oder zwischen Datenbanken und anderen Programmen. Es ist jedoch selbst keine Datenbank. Verwenden Sie es nicht wie eine. “- Effektives XML: 50 spezifische Möglichkeiten zur Verbesserung Ihres XML von Elliotte Rusty Harold (Seite 230, Teil 4, Punkt 41, 2. Absatz)

Dies scheint wirklich zu betonen, dass XML nicht für die Datenspeicherung und nur für die Interoperabilität von Programm zu Programm verwendet werden sollte.

Persönlich bin ich anderer Meinung und die .NET- app.configDatei, die zum Speichern der Einstellungen eines Programms verwendet wird, ist ein Beispiel für die Datenspeicherung in einer XML-Datei. Für Datenbanken und nicht für Konfigurationen usw. sollte jedoch XML nicht verwendet werden.

Um meinen Standpunkt zu erläutern, verwende ich zwei Beispiele:
A) Daten zu Kunden mit Feldern, die alle auf einer Ebene liegen, dh es gibt eine Reihe von Feldern, die sich alle auf einen Kunden ohne Kinder beziehen.
B) Daten zur Konfiguration einer Anwendung mit verschachtelten Feldern und Eigenschaften machen sehr viel Sinn

Meine Frage lautet also: Ist dies noch eine gültige Aussage und ist es jetzt akzeptabel, Daten mit XML zu speichern?

BEARBEITEN: Ich habe eine E-Mail an den Autor dieses Zitats gesendet, um ihn um seine Eingabe / seinen zusätzlichen Kontext zu bitten.

In diesem Zitat geht es nicht um die Verwendung von XML als Speicherformat im Allgemeinen (für das es je nach Anforderung in Ordnung ist), sondern um die Speicherung in Form einer Datenbank .

Wenn von Datenbanken die Rede ist, sind damit normalerweise Speichersysteme gemeint, die große Datenmengen speichern , häufig im Gigabyte- oder Terabyte-Bereich. Eine Datenbank ist möglicherweise viel größer als der verfügbare Arbeitsspeicher auf dem Server, auf dem sie gespeichert ist. Da niemand alle Daten in einer Datenbank auf einmal benötigt, sollten Datenbanken für den schnellen Abruf ausgewählter Teilmengen ihrer Daten optimiert werden: Dafür ist die SELECTAnweisung gedacht, und relationale Datenbanken sowie NoSQL-Lösungen optimieren ihr internes Speicherformat schnell Abrufen solcher Teilmengen.

XML erfüllt diese Anforderungen jedoch nicht wirklich. Aufgrund seiner verschachtelten Tag-Struktur ist es nicht möglich zu bestimmen, wo in der Datei ein bestimmter Wert gespeichert ist (in Form eines Byte-Versatzes in einer Datei), ohne den gesamten Dokumentbaum zu durchlaufen, zumindest nicht bis zur Übereinstimmung. Eine relationale Datenbank hat Indizes, und das Nachschlagen eines Wertes in einem Index, selbst bei einer primitiven Binärsuchimplementierung, ist eine einzelne Suche nach O (log n), und das Abrufen der tatsächlichen Werte ist nichts anderes als eine Dateisuche (z. B. fseek(data_file_handle, row_index * row_size)), das ist O (1). In einer XML-Datei können Sie am effizientesten einen SAX-Parser für Ihr Dokument ausführen, der eine Menge Lesevorgänge und Suchvorgänge ausführt, bevor Sie zu Ihren eigentlichen Daten gelangen. Sie können dies kaum besser als O (n) erreichen, es sei denn, Sie verwenden Indizes. Dann müssten Sie den gesamten Index für jede Einfügung neu erstellen (siehe unten).

Das Einfügen ist noch schlimmer. Relationale Datenbanken garantieren keine Zeilenreihenfolge, dh, sie können nur neue Zeilen anhängen oder als "gelöscht" markierte Zeilen überschreiben. Dies ist extrem schnell: Die DB kann nur einen Pool beschreibbarer Speicherorte in der Nähe aufbewahren. einen Eintrag aus dem Pool zu erhalten, ist O (1), es sei denn, der Pool ist leer; Im schlimmsten Fall ist der Pool leer und es muss eine neue Seite erstellt werden, aber auch dies ist O (1). Im Gegensatz dazu müsste eine XML-basierte Datenbank alles nach der Einfügemarke verschieben, um Platz zu schaffen. das ist O (n). Wenn Indizes ins Spiel kommen, wird es noch interessanter: Typische relationale Datenbankindizes können mit relativ geringer Komplexität aktualisiert werden, z. B. O (log n); Wenn Sie jedoch Ihre XML-Dateien indizieren möchten, ändert jede Einfügung möglicherweise den Speicherort jedes Werts im Dokument, sodass dies erforderlich istErstellen Sie den gesamten Index neu . Dies gilt auch für Aktualisierungen, da durch die Aktualisierung beispielsweise des Textinhalts eines Elements dessen Größe geändert werden kann, was bedeutet, dass die aufeinanderfolgende XML-Datei verschoben werden muss. Eine relationale Datenbank muss den Index überhaupt nicht berühren, wenn Sie eine nicht indizierte Spalte aktualisieren. Eine XML-Datenbank müsste den gesamten Index für jede Aktualisierung neu erstellen, die die Größe des aktualisierten XML-Knotens ändert.

Das sind die wichtigsten Nachteile, aber es gibt noch mehr. XML ist sehr ausführlich, was gut für die Server-zu-Server-Kommunikation ist, da es die Sicherheit erhöht (der empfangende Server kann alle Arten von Integritätsprüfungen für XML durchführen, und wenn bei der Übertragung etwas schief gelaufen ist, ist es unwahrscheinlich, dass das Dokument validiert wird ). Für den Massenspeicher ist dies jedoch tödlich: Es ist nicht ungewöhnlich, dass der Overhead für XML-Daten 100% oder mehr beträgt (es ist nicht ungewöhnlich, dass Overhead-Verhältnisse im Bereich von 1000% für SOAP-Nachrichten angezeigt werden), während für relationalen DB-Speicher typisch ist Schemata haben nur einen konstanten Overhead für Tabellenmetadaten plus ein winziges Bit pro Zeile. Der größte Teil des Overheads in relationalen Datenbanken stammt aus festen Spaltenbreiten. Wenn Sie ein Terabyte an Daten haben, ist ein Overhead von 500% aus vielen Gründen einfach nicht akzeptabel.

XML ist schlecht für die Datenspeicherung. Erstens ist es sehr ausführlich. In einer XML-Datei gespeicherte Daten belegen viel mehr Speicherplatz als dieselben Daten, die in einem vernünftigen Datenbanksystem gespeichert sind. In einem XML-Datensatz wird der Name eines bestimmten Felds zusammen mit der Zeichenfolgendarstellung der Daten zweimal gespeichert. Wenn Sie beispielsweise eine einzelne Ganzzahl in einem Feld namens "foobar" speichern möchten, erhalten Sie diese 19-Byte-Zeichenfolge:

<foobar>42</foobar>

Auf der anderen Seite speichert eine echte Datenbank diesen Wert als einzelnen Integarwert, der 4 Bytes benötigt. Wenn Ihre Datenbank klein ist, bedeutet das nicht viel, aber wenn Sie 10.000 Datensätze haben, ist das ein Problem.

Zweitens muss jedes Mal, wenn die Datei gelesen wird, eine XML-Datei aus dem Text analysiert werden. Für das obige Feld liest eine echte Datenbank einfach die Binärdaten aus dem Offset in den Speicher, in dem sie das Feld "foobar" gespeichert hat. Wenn die Datei als XML gespeichert ist, muss sie das Feld "foobar" lesen und diesen Text analysieren Bestimmen Sie, welches Feld es ist, analysieren Sie dann die Zeichenfolge "42" und konvertieren Sie sie in die Binärdatei 42.

Daher sind die Performance-Nachteile für die Verwendung von XML enorm. Der Vorteil von XML besteht darin, dass es einigermaßen für den Menschen lesbar ist und eine einfache Datenübertragung zwischen vollständig getrennten Systemen ermöglicht. Keiner dieser Vorteile gilt für eine lokale Datenbank.

Die einzige Ausnahme sind Konfigurationsdateien, die im Allgemeinen klein sind und von Menschen bearbeitet werden müssen.

Eine XML-Datenbank ist absolut größer und langsamer als jedes vernünftige SQL-System. Wenn die Lesbarkeit oder Interoperabilität des Menschen keinen ausgleichenden Vorteil bietet, macht es keinen Sinn, sie für die Datenspeicherung zu verwenden.

XML ist je nach Kontext sinnvoll. Wenn Ihre Daten ziemlich statisch sind und sich nicht wesentlich ändern (z. B. Beispieldaten), ist XML eine gute Verwendung.

Konfigurationseinstellungen und Beispieldaten (selbst wenn sie Millionen von Zeilen umfassen, sich jedoch nur selten ändern) sind gute Verwendungen von XML.

Festplatten-Lese- / Schreibvorgänge sind teurer als der Zugriff auf Daten von einem Oracle / SQL-Stapel.

Dies scheint wirklich zu betonen, dass XML nicht für die Datenspeicherung und nur für die Interoperabilität von Programm zu Programm verwendet werden sollte.

Ihre Prämisse ist fehlerhaft.

Der Absatz, den Sie zitieren, besagt tatsächlich, dass XML kein Ersatz für eine Datenbank ist und nicht für die Datenspeicherung verwendet werden sollte .

Es ist klar, dass eine Einstellungsdatei nicht dasselbe ist wie eine Datenbank, und daher können (und sollten?) Verschiedene Technologien verwendet werden.

Korrigieren Sie mich, wenn ich falsch liege, aber Sie scheinen mehr Erfahrung mit Auszeichnungssprachen zu haben als mit Datenbanken. Wenn Sie ein wenig Erfahrung mit Datenbanken haben, werden Sie feststellen, für welche Bereiche die beiden unterschiedlichen Technologien geeignet sind.

Das ist wirklich subjektiv. Dieses Zitat ist wie jemandes Meinung, Mann.

Ehrlich gesagt denke ich, dass XML eine praktikable Alternative zu einer Datenbank ist, da es mehrere Vorteile gegenüber einem RDMS bietet, einschließlich eines geringen Overheads, der billigerem Speicher entspricht (insbesondere wenn ein Hosting-Service verwendet wird, für den Datenbanken separat berechnet werden).

Schauen Sie sich dasBlog und BlogEngine an . Beide Anwendungen verwenden standardmäßig XML für die Speicherung.

Das gesagt. Es ist kein RDMS. Wenn Ihre Daten sehr volatil sind (viele Aktualisierungen, Einfügungen oder Löschungen) oder eine hohe Verfügbarkeit erfordern, verwenden Sie eine Datenbank. XML eignet sich gut zum Speichern kleiner Daten wie Konfigurationsdaten und Daten mit geringer Flüchtigkeit.

meine frage ist, ist dies noch eine gültige aussage und ist es jetzt akzeptabel, daten mit xml zu speichern?

Ich sehe Ihren Standpunkt in Ihrem Beispiel zu .NET-Konfigurationsdateien. Es hätte jedoch jedes andere Dateiformat verwendet werden können. Früher wurden solche Einstellungen in regulären Textdateien gespeichert, die als INI-Dateien bezeichnet wurden.

Ich sehe, dass die Aussage, die Sie in grau dargestellt haben, gültig und richtig ist, wenn Sie eine Datenbank als Softwaresystem definieren.

Die Definition von XML in XML-Definition besagt, dass "(XML) eine Auszeichnungssprache ist, die eine Reihe von Regeln für die Codierung von Dokumenten in einem Format definiert, das sowohl für Menschen als auch für Maschinen lesbar ist."

Diese Definition konzentriert sich eher auf Lesbarkeit und Sprache als auf Mechanismen zur Verwaltung der Daten.

Im Vergleich zu einem RDBMS bietet XML keine Möglichkeit, Zeilen in eine XML-Datei nach dem Zufallsprinzip einzufügen und zu löschen. Wenn Sie beispielsweise über 1000000 Zeilen verfügen und selbst in einer XML-basierten Datei für eine einzelne Benutzerumgebung willkürlich Zeilen löschen möchten, ist dies keine gute Wahl für eine Datenbank. XML bietet auch keine systemeigenen Mechanismen zum Sperren von Daten. Da XML keine Software ist, müssen alle ACID-Eigenschaften (Atomicity, Consistency, Isolation, Durability), die gewährleisten, dass Datenbanktransaktionen in einer gemeinsam genutzten Umgebung zuverlässig verarbeitet werden, vom Entwickler erstellt werden (mit Ausnahme von Durability). XML hat keine robuste Spezifikation, um die Datenintegrität in allen XML-Dateien zu gewährleisten, geschweige denn auf verschiedenen Servern (z. B. XML-Kundendatei und XML-Bestelldatei - Keine FKs zur Durchsetzung der Integrität).

Das ist oben nicht eine Aufzählung dessen , was XML fehlt, sondern es konnte Server als eine schnelle Begründung der Aussage , dass XML nicht eine Datenbank - Software .

XML sollte niemals eine Datenbank sein oder diese ersetzen.

XML ist hauptsächlich für Webdokumente definiert allows for the creation of customized tags for individual information fields., mit denen Sie jedoch niemals ein relationales zentrales Datenmanagement erzielen würden.

Warum sollten Sie eigentlich XML zum Speichern von Daten verwenden ? Ich meine, es ist doch eine Sprache ...

Man könnte argumentieren, dass es sich um ein flexibles und leicht verständliches Format handelt, das jedoch nur dann gilt, wenn Sie die Dateien manuell bearbeiten müssen. Wenn Sie tatsächlich mit der Datenbank über eine gemeinsame Schnittstelle interagieren (Daten X abrufen, die die Anforderungen Y und Z erfüllen, Daten X speichern / aktualisieren, ...), werden diese Vorteile ungültig.

Kurze Antwort: Es kommt darauf an.

Lange Antwort: Aus meiner Sicht hängt dies stark von der Datenmenge ab, die Sie speichern möchten. Wenn Sie beispielsweise zur Laufzeit einige Objekte in Ihrer Anwendung haben und diese nach dem Ausführen des Tools speichern möchten, ist eine XML-Datei in Ordnung. Wenn Ihr Webshop jedoch 5.000 Kunden und noch mehr Bestellungen hat, ist eine Datenbank ein geeigneterer Datenspeicher.

Außerdem denke ich, dass das Speichern von Einstellungen in einer Datenbank und nicht in einer Datei wie app.config in den meisten Fällen nicht sehr nützlich ist, aber ich denke nicht, dass dieses Beispiel das Zitat als falsch erweist.

XML ist eine ausgezeichnete Wahl für Konfigurationseinstellungen. XML-Dateien können in einer IDE nicht nur leicht analysiert / hervorgehoben werden, sie sind auch für Nicht-Programmierer sehr einfach zu bearbeiten. Ich finde sie unglaublich nützlich in Webentwicklungsszenarien, in denen Wartungsaufgaben von Designern und Content-Managern ausgeführt werden.

XML sollte normalerweise nicht als primäre Datenquelle für nicht triviale Anwendungen verwendet werden. Allein der Aufwand für die Serialisierung / Deserialisierung erfordert eine andere Lösung.

Der Begriff Datenbank kann sich entweder nur auf die Rohdaten oder auch auf das Datenbankverwaltungssystem beziehen. Diese Definition macht einen großen Unterschied im gesamten Argument.

Wenn wir die RDBMS-Definition verwenden, hat XML in diesem Sinne sehr wenig. Sie erhalten sehr wenig in Bezug auf ACID-Garantien (Sie müssten Ihren eigenen Code schreiben, um diese zu erreichen). Wenn Sie diese benötigen (und die meisten Transaktionssysteme), sind Sie bereits in großen Schwierigkeiten. Ich könnte eine Liste mit Hunderten von Funktionen erstellen, die für RDBMS-Systeme selbstverständlich sind und die Sie neu erfinden und neu implementieren müssen. Denken Sie an Sicherheitsmodelle, Replikation, Backups, um nur einige grundlegende zu nennen.

Im obigen Sinne ist XML keine Datenbank, und Sie sollten nicht versuchen, es als eine zu verwenden.

Wenn wir die "Rohdaten" -Definition verwenden, ist XML viel besser, aber immer noch nicht so gut. Wie andere bereits betont haben, ist es im Allgemeinen sehr ausführlich, es fehlt in der Regel die Binärkodierung und es gibt doppelte Tags usw. Diese Kompromisse wurden getroffen, damit XML für den Menschen lesbar ist - im Grunde ist Effizienz der Feind dieser Anforderung . XML eignet sich auch nicht besonders für die einfachsten Situationen, in denen Sie fortlaufend Datensätze einfügen. Angenommen, Sie möchten, dass Ihre XML-Datei gültig ist, benötigen Sie ein einzelnes schließendes Tag. Wenn Sie also einen Datensatz anhängen, müssen Sie die Tags am Ende nach oben verschieben. Dies ist ziemlich teuer (woher wissen wir, wo dieses Tag beginnt? Was ist, wenn es mehrere "Tabellen" gibt, verschieben wir einfach die gesamte Datei nach oben?) Und wenn Sie es umgehen möchten, müssen Sie

Es gibt Situationen, in denen XML angemessen ist - Konfigurationsdateien sind ein hervorragendes Beispiel, da sie normalerweise klein sind und die Lesbarkeit für den Menschen eine hervorragende Funktion darstellt. Eine Datenbank nur für eine Konfigurationsdatei zu haben, ist möglicherweise zu viel des Guten.

Datenbanken hingegen eignen sich hervorragend, wenn Sie über Tausende (oder Millionen / Milliarden) Datensätze verfügen und diese von vielen Benutzern gleichzeitig aktualisiert werden. Also ja, XML ist keine Datenbank, und Sie sollten es nicht wie eine verwenden. Ihr Beispiel ist eine der Situationen, in denen Sie ursprünglich keine Datenbank benötigten und XML besser passt.

Ich sehe das so: Wenn Sie XML als Datenbank verwenden (z. B. als Backup-Speicher für ein Transaktionssystem), werden Sie ein RDBMS neu erfinden und neu schreiben . Das ist eine wirklich schlechte Art, Zeit und Energie zu verbringen. Ich denke, das hat auch dieses Zitat gesagt.

Ich stimme zu, dass es keine relationale Datenbank ist. Ich denke, der Autor sagt einfach im Zitat, dass er es nicht als eins verwenden soll.

Allerdings kann es sein, dass Sie eines brauchen oder nicht. Wenn Sie die Daten nicht wirklich abfragen müssen und sie nur speichern und später anhand einiger eingeschränkter Abfragekriterien abrufen möchten, müssen Sie XML DOCUMENT speichern und abrufen - keine relationale Datenbank.

Es gibt viele Anwendungen, in denen einfach ein Dokument mit Daten gespeichert werden muss, damit es später wieder vollständig abgerufen werden kann. Wenn dies der Fall ist, ist es sinnlos, ein SQL-basiertes Schema zu erstellen, das XML zu analysieren und es dann in die Datenbank zu serialisieren, um später genau das Gegenteil zu tun. Es gibt eine Menge Code-Overhead, der möglicherweise damit verbunden ist. Es gibt jedoch weniger, wenn Sie es richtig machen.

Sie können ORM-Tools wie Hibernate und Tools wie Apache Axis verwenden, um praktisch den gesamten Code automatisch zu generieren, den Sie zum Erstellen eines Dienstes benötigen, der nur einfache CRU-Vorgänge verarbeitet. Sie müssten dies natürlich in die Authentifizierung einbeziehen und möchten möglicherweise die Daten nach Benutzer, Zugriffsebene usw. trennen. Sie möchten möglicherweise sogar einschränken, für welche Vorgänge ein bestimmter Benutzer über den SOAP-Dienst berechtigt ist Beispiel.

In diesem Sinne machen Sie mehr wie Content Management als alles andere.