Was sind die Vorteile des Speicherns von XML in einer relationalen Datenbank?

Ich habe mich heute in der AdventureWorks-Datenbank umgesehen und festgestellt, dass einige Tabellen ( HumanResources.JobCandidateund Sales.Individualzum Beispiel) eine Spalte enthalten, in der XML-Daten gespeichert sind.

Was ich wissen möchte, ist, was der Vorteil ist, wenn Sie die Daten einer Datenbanktabellenzeile grundsätzlich in der Spalte einer anderen Tabelle speichern? Ist es nicht schwierig, diese Informationen abzufragen? Oder ist die Annahme, dass die Daten nicht abgefragt und nur gespeichert werden müssen?

Da nicht alle Daten relational gespeichert werden müssen und das Schreiben von Code zur Verarbeitung von Daten, die Sie als XML für die relationale Speicherung übergeben haben, zeitaufwändig (und sehr, sehr mühsam) ist. Dies gilt insbesondere dann, wenn viele XML-Daten von Systemen stammen, die große generische Antworten auslösen.

Ich habe häufig Situationen erlebt, in denen eine Nachricht von einem anderen System empfangen wurde und es uns egal ist, zu 98%, was sie enthält. Wir analysieren es also, um die 2%, die uns wichtig sind, aufzuteilen, relational zu speichern und dann die gesamte Nachricht zu speichern, falls wir die restlichen 98% später benötigen.

Und SQL Server bietet Ihnen einige nützliche Tools und Syntax für die Arbeit mit XML in T-SQL, sodass Ad-hoc-Abfragen nicht unmöglich sind einer CSV.

Und das schließt die Möglichkeit aus, dass das, was Sie tatsächlich speichern möchten, XML ist (zum Beispiel für Support- und Debug-Zwecke) ...

Wenn das Datenformat flüchtig ist und möglichen Änderungen unterliegt, möchten Sie es möglicherweise als XML zusammenstellen und in dieser Form in die Datenbank einfügen, um zukünftige Änderungen des Datenbankschemas zu vermeiden.

Wenn die Daten von einem externen System bereitgestellt und von diesem wieder verwendet werden und Sie nicht in der Lage sind, ein dauerhaftes Format bereitzustellen, ist dies genau das, was Sie tun würden.

Ist es nicht schwierig, diese Informationen abzufragen?

SQL Server kann XML-Felder und -Variablen abfragen. Nicht unbedingt schwierig, aber mehr Arbeit, ja. Aber machbar.

Nach meiner Erfahrung werden die XML-Daten normalerweise gespeichert und nur selten abgefragt, aber häufig bei Bedarf extrahiert, normalerweise, wenn ein anderes System eine XML-Darstellung einiger Daten benötigt, die möglicherweise nur schwer oder gar nicht direkt aus relationalen Daten generiert werden können. Die XML-Daten werden möglicherweise von einem anderen Prozess vorab ausgefüllt.

Wenn Sie sich vorstellen können, Ihre Daten in einem binären Stream in einem Blob zu speichern, können Sie sich vorstellen, Ihre Daten in einem XML-Format in einem Blob zu speichern.

Natürlich bleiben viele Dinge am besten in der Vorstellung des Imaginators.

Zum Beispiel elektronische Patientenakten:

Da würden Sie höchstwahrscheinlich das ASCII HL7 V2.x in einem Feld in einer Datenbank speichern. Sie können HL7 V3.0 wahrscheinlich in einem Feld in einer Datenbank speichern.

Der Vorteil ist also die Bequemlichkeit.

Ich arbeite derzeit an einem Projekt, das dies tut. Wir haben Daten, die mehrfach verarbeitet und relational gespeichert werden müssen. Die Verarbeitung erfolgt jedoch in Java, und es ist einfacher, dort mit XML zu arbeiten. Wir führen also einen einmaligen Durchlauf durch die relationalen Daten durch und speichern sie als XML in einer Tabelle. Dann können wir diese Daten in Java mit einer einzigen Abfrage verarbeiten, anstatt jedes Mal Daten abzurufen, und dieselben Daten immer wieder nach Herzenslust verarbeiten. Es ist viel einfacher und effizienter.

Ein gutes Beispiel für das Speichern von XML ist, wenn Sie Benutzeroberflächenzustände in der Datenbank beibehalten möchten. Der Status aller Anwendungsansichten wird serialisiert und in der Datenbank gespeichert, und es ist nicht erforderlich, das XML abzufragen. Mit UI-Status meine ich, Sortierreihenfolge der Ansicht, Größe der Fenster usw.

Oft erhalten Sie gemischte Daten, die sowohl XML als auch relational sind. (Ein gutes Beispiel hierfür ist ein Dokumentenspeicher, in dem jedes Dokument Metadatenfelder wie Titel, Erstellungsdatum, Eigentümer usw. enthalten kann.)

Zu diesem Zeitpunkt müssen Sie aus drei Optionen auswählen:

1. Speichern Sie alles in einer relationalen Datenbank.
2. Speichern Sie alles in einer nativen XML-Datenbank.
3. Speichern Sie Daten in zwei separaten DBs, XML in nativem XML und Metadaten in relationalen Datenbanken.

Option 3 ist wahrscheinlich die sauberste, aber auch die teuerste und am schwierigsten zu implementierende Option. Außerdem möchten Sie nicht unbedingt verteilte Transaktionen in einem nicht sehr großen System. Option 2 ist nicht sehr gut, da native XML-Datenbanken in der Regel sehr schlecht mit relationalen Daten umgehen (die Sie eher für Suchvorgänge verwenden) und die Technologie insgesamt weniger ausgereift ist als relationale Datenbanken.

So bleibt Ihnen mit Option 1 sicherlich nicht die beste Lösung, aber vielleicht die am wenigsten schlechte.

Ich habe die Erfahrung gemacht, dass XML in einer Datenbank verwendet wird, weil es auf diese Weise in der Datenquelle gespeichert wird oder wenn Sie es zu einer vorhandenen Datenbank hinzufügen, um die Funktionalität so zu erweitern, dass keine umfangreiche Datenbankprogrammierung erforderlich ist .

Wenn Sie häufig nach den neuen Daten suchen, ist es möglicherweise sinnvoll, die XML-Datei stattdessen in ihre Bestandteile aufzuteilen. Ist dies nicht der Fall, kann dies eine nützliche Methode sein, um selten geänderte Daten zu speichern.

Hoffe das hilft, Jeff

Dokumentenorientierte Datenspeicher (auch bekannt als NoSql) sind heutzutage sehr beliebt:

http://en.wikipedia.org/wiki/Document-oriented_database

Es gibt keinen Grund, warum Sie in einer relationalen Datenbank kein dokumentenorientiertes Schema verwenden können. Sie erhalten möglicherweise nicht alle Vorteile im Vergleich zu Mongo, aber Sie werden auch nicht die Nachteile haben.

Wenn Sie dokumentenorientierte Speicherung verwenden möchten, müssen Sie lange Zeit strukturierte Daten (wie XML) in eine große Spalte verschieben. Die relationalen Datenbanken haben Funktionen wie Indizierung und Matching hinzugefügt, um dies zu unterstützen.

Vergleichen Sie das mit Mongo, wo es nur Dokumente in der Datenbank gibt. Aber das ist ein anderes Thema.

BEARBEITEN: Die Grundidee von dokumentenorientierter Arbeit ist: Sie ziehen die Daten heraus, bearbeiten sie und schieben sie vollständig zurück. Manchmal möchten Sie, wie beim Übertragen des Dokuments an den Kunden, nur das gesamte Dokument als Blob senden und es von ihnen bearbeiten lassen. Der Vorteil (und Nachteil) ist Flexibilität. Die Validierung und Richtigkeit des Dokuments erfolgt außerhalb der Datenbank.

EDIT EDIT: Ein weiterer Kontrast. Stellen Sie sich vor, Sie speichern JPG-Bilder oder Word-Dokumente in einer Datenbankspalte.

Was sind die Vorteile des Speicherns eines Baums (XML) in einer Liste von Tupeln (einer Datenbanktabelle)?

Es gibt keinen Grund, warum das XML nicht mit XPath oder SPARQL von Ihrem DBMS abfragbar sein sollte.

Aus meiner Sicht handelt es sich lediglich um zwei unterschiedliche Datenstrukturen. Und es gibt keinen Grund, warum sie nicht ineinander eingebettet werden sollten.

Sie können nach den Gründen suchen, warum der JSON-Datentyp in PostgreSQL hinzugefügt wurde. Ich denke, dass viele der gleichen Argumente zutreffen. Mit Ausnahme von XML / XSD ist noch mehr Validierung möglich.

Nun, XML (oder JSON) ist ziemlich gut, um Metadaten mit Hierarchie zu speichern. Was sind die Alternativen? Eine Metadatentabelle mit refid / key / value / depth vielleicht? Es ist ein bisschen umständlich (aber wahrscheinlich besser für die Abfrage, wenn Sie es tun müssen). Das Speichern von XML-Daten zu einem Dokument (eine Zeile in einer Dokumententabelle) ist sehr praktisch, wenn Sie hierarchische Informationen speichern möchten, ohne sich auf eine externe Tabelle verlassen oder 1 Spalte pro "Typ" von Informationen hinzufügen zu müssen.

Ich würde sagen, es war eine schlechte Praxis, da Sie den ansonsten effizienten Speicher mit ineffizienten Tags verstopfen, die nicht vorhanden sein müssen, wenn Sie sich die Mühe machen, die Informationen zu analysieren. XML hat im Vergleich zu den beschriebenen Daten einen abscheulichen Speicheraufwand, da Sie für jede Spalte und jede Zeile ein Tag benötigen. Im Vergleich dazu wird der Spaltenname von Daten, die analysiert und im relationalen Format gespeichert wurden, EINMAL gespeichert. Für ein Dutzend Reihen auf einem Entwickler. Box, große Sache, aber ich habe gesehen, dass Entwickler die Annahme gemacht haben, dass dies auf Millionen von Zeilen skalierbar ist. Dies kann 100 GB Overhead für ein paar Dutzend GB Daten bedeuten, was zu betrieblichen Herausforderungen führt. Sie verzichten im Grunde genommen auf Ihre Verantwortung und drängen auf die Leute, die den Mist unterstützen müssen, den Sie geschrieben haben.

Warum speichern Sie es also nicht FERN aus den Betriebsdaten in einer eigenen Datenbank? Oder wie es gedacht ist - in flachen Dateien? Es wird wahrscheinlich nie wieder angezeigt. Warum sollte es nicht entfernt werden, um die Leistung eines Betriebssystems zu beeinträchtigen? Denken Sie daran, dass XML NUR dazu dient, eine Beschreibung des Datenschemas bereitzustellen, die ansonsten aufgrund von Unterschieden im Speicherprotokoll zwischen Systemen nicht ersichtlich wäre. Das ist der ganze Punkt, es ist nichts Schlaues daran. Das 10-fache des Overheads für eine bestimmte Datenmenge bedeutet lediglich, dass Sie ein schlampiger Entwickler sind, der nicht durchdacht ist und nicht in der Lage ist, die von Ihnen verbrauchten Daten in ein vernünftiges, effizientes und schnell abfragbares Format umzuwandeln. Hören Sie auf, Ihre Bemühungen auf den operativen Support zu lenken, und überlegen Sie, wie Sie die Daten nach der Installation besser verarbeiten können. Ich habe es erhalten, wäre mein Anruf. Es gibt keine Möglichkeit, Daten nach dem Empfang als XML zu speichern, da sie ihren Zweck erfüllen.