Wann sollte ich den XML-Datentyp in SQL Server verwenden?

Wann sollte ich den XML-Datentyp in Microsoft SQL Server verwenden?

Ähnlich habe ich es gemacht, indem ich Objektdaten für die Speicherung in XML serialisiert habe. Dadurch entfällt die Belastung durch Tabellen, Spalten und Beziehungen, in denen Daten für komplexe Objekte gespeichert werden. Der Prozess kann durch die Verwendung eines Schemas unterstützt werden, dem das XML-Ergebnis entspricht, und die Datenbanktabellen können für Metainformationen zu den betreffenden Objekten verwendet werden. In meinem Fall wäre das Erweitern des Datenbankschemas zur Anpassung an das Objektlayout eine große Aufgabe!

Persönlich habe ich den XML-Feldtyp noch nie in SQL Server verwendet und seit dem Hinzufügen dieser Funktion viel Datenbankprogrammierung durchgeführt. Ich hatte immer den Eindruck, dass die native Verwendung von XML-Inhalten in einer Datenbank einen programmatischen und Performance-Mehraufwand mit sich bringt. Ich habe ehrlich gesagt gedacht, dass es ein Trick ist, weil alle in den frühen 2000er Jahren einmal im XML-Zug waren. "Oh, XML ist heiß, also fügen wir es zu SQL Server hinzu, damit wir nicht passe aussehen."

Der beste Geschäftsfall, den ich sehen kann, ist das Aufzeichnen von XML-basierten Datennachrichten, bei denen Sie möglicherweise einen Blick auf ihre Struktur und Daten werfen möchten, die Integrität der ursprünglichen Nachricht jedoch aus geschäftlichen oder rechtlichen Gründen beibehalten möchten. Der Aufwand ist möglicherweise zu groß, um das XML in eine Tabellenstruktur zu übersetzen. Die Verwendung der XML-Funktionen in SQL Server kann jedoch die Kosten für die Prüfung der Daten verringern, um die Verwendung zu rechtfertigen.

Es gibt wahrscheinlich Dutzende anderer Gründe, warum Sie es verwenden möchten, aber ehrlich gesagt sollten Sie andere Wege in Betracht ziehen, bevor Sie mit XML in SQL Server wild werden, es sei denn, Sie haben ganz bestimmte geschäftliche Gründe dafür. Verwenden Sie ein varchar (max) oder ein Textfeld, wenn es sinnvoller ist.

Nur meine Meinung natürlich :)

Ich habe nur einige Szenarien erlebt, in denen ich die Verwendung des XML-Datentyps in SQL Server aktiv verfolgen würde. Das ist mir ein Rätsel, von der geringsten bis zur interessantesten:

• Speichern / Archivieren von XML-Antworten, die von anderen Anwendungen generiert wurden
  • Beispielsweise verwenden wir das Application Integration Framework (AIF) für die Kommunikation zwischen einer benutzerdefinierten Silverlight-Anwendung und Dynamics AX. Wir speichern sowohl eingehende als auch ausgehende Nachrichten in der Datenbank, um die Fehlerbehebung bei der Kommunikation zwischen diesen Anwendungen zu unterstützen
  • Da es sich bei dem Feldtyp nicht um einen generischen String-Typ (dh VARCHAR), sondern um XML handelt, können wir mithilfe von XQuery gezielt nach Nachrichten suchen, die bestimmten Kriterien entsprechen. Dies wäre bei einem einfachen String-LIKE-Matching sehr viel schwieriger
• Eine zusammengesetzte Antwortnachricht zwischenspeichern / beibehalten
  • Aktualisieren Sie das XML-Feld mit einem Trigger- oder Anwendungscode, der eine berechnete Spalte imitiert
  • Anstatt eine XML-Antwort auf der Basis einer aufrufenden Anwendung ständig neu zu generieren, würde sich der Aufwand nur beim Hochfahren der Zeile und nicht bei jedem Aufruf erhöhen
  • Dies funktioniert am besten, wenn SELECTs viel häufiger als UPDATEs / INSERTs sind, was für die meisten Anwendungen eher zutrifft
• Speichern mehrerer Werte in einem einzigen Feld
  • Eine der Methoden, die ich gesehen habe, ist die Verwendung des XML-Datentyps zum Speichern einer Sammlung von Werten in einem einzelnen Feld
  • Ein Vorteil ist, dass Sie keine zusätzlichen Tabellen für einen einfachen Schlüssel- / Wertspeicher entwerfen müssen
  • Ein Nachteil davon ist, dass die Daten nicht vollständig normalisiert sind, was die Abfrage weniger offensichtlich macht
  • Wie oben erwähnt, können Sie jedoch XQuery für dieses XML-Feld verwenden, um Zeilen auszuwählen, die den Identifizierungskriterien entsprechen, wodurch die Auswirkungen einer nicht vollständigen Normalisierung teilweise nuetralisiert werden.

Trotzdem brauche ich in 99% der Fälle kein XML-Feld, um ein Schema zu entwerfen.

In den wenigen Fällen, in denen ich den XML-Datentyp in SQL Server gesehen habe, wurde er im Grunde genommen als Feld verwendet, das wie jedes andere Feld in der Datenbank abgefragt wurde. Dies kann bei großen Datenmengen zu sehr schlechten Auswirkungen auf die Leistung führen . Es gibt einen Grund, warum es SQL Server und nicht XML Server heißt. :-) Die Abfragen, die gegen das XML gehen, sind einfach nicht so schnell wie eine normale Auswahlabfrage.

Ich konnte sehen, dass es verwendet wird, um XML zu speichern, das jedoch nicht so häufig abgefragt wird, z. B. das Speichern des vollständigen XML-Dokuments in einem XML-Datentyp, aber das Speichern der durchsuchbaren Felder (Schlüssel) separat mit dem XML-Dokument. Auf diese Weise können Sie Ihre Informationen schneller abfragen und das XML-Dokument aufrufen, wenn Sie den Punkt erreichen, an dem Sie das vollständige Dokument anzeigen möchten. Eigentlich musste ich dies mit einer Reihe von Apps tun, bei denen versucht wurde, den XML-Datentyp als stark abgefragtes Feld zu verwenden, und die Daten bis zu einem Punkt gewachsen sind, an dem die Abfrage zu langsam geworden ist.

Ich habe XML-Felder hauptsächlich zu Protokollierungszwecken im Zusammenhang mit ASMX-Webdiensten oder WCF-Diensten verwendet. Sie können die Anforderungs- oder die Antwortnachrichten speichern.

In den meisten Fällen speichern Sie das XML in der Datenbank zu Referenzzwecken - nicht für Ihre reguläre Geschäftstätigkeit (nicht um es alle 5 Sekunden aus dem Code abzufragen). Bestimmen Sie in diesem Fall die Felder, die Sie normalerweise abfragen oder meistens verwenden, und erstellen Sie separate Spalten. Auf diese Weise können Sie beim Speichern der XML-Datei in der Datenbank diese Felder extrahieren und in den entsprechenden Spalten speichern. Später, wenn Sie sie abrufen, müssen Sie das XML-Dokument nicht mehr abfragen. Sie können nur die Spalten verwenden, die Sie für diesen Zweck erstellt haben.

Dies sind die Szenarien, die Ihnen spontan einfallen, wenn Sie überlegen, welche Bedingungen erforderlich sind, um XML-Felder in SQL Server zuzulassen:

• Binärdaten, die für den Austausch codiert sind, wenn Sie eine saure Kontrolle über die Ressource wünschen
• Dokumentieren Sie Fragmente, die mithilfe dynamischer Informationen vollständig wiederhergestellt werden
• Vom Benutzer eingereichte Dokumente oder Fragmente, die Sie isolieren möchten, halten das Dateisystem direkt fern.

Ich verwende XML häufig in Client-Server-Apps, um strukturierte Daten in einem einzigen Aufruf der Datenbank zu speichern. Nehmen Sie als Beispiel eine Rechnung mit Detailzeilen. Es ist ganz einfach, dass der Client das Geschäftsobjekt in XML serialisiert und in einem einzigen Aufruf an einen gespeicherten Prozess übergibt. Die Prozedur entscheidet, ob eine Einfügung oder Aktualisierung erforderlich ist; Es kann die übergeordnete Rechnungs-ID (eine Identitätsspalte) erhalten, um sie den Detailsätzen zuzuweisen, und zwar alle innerhalb einer serverseitigen Transaktion und ohne dass der Kunde mehrere Roundtrips durchführen muss. Ich benötige nicht etwa 20 Parameter, um den Header-Datensatz anzugeben, und ich muss nicht für jeden Rechnungsposten einen Anruf tätigen. Außerdem ist es häufig möglich, Schemaänderungen vorzunehmen oder Protokollierung / Überwachung einzuführen, ohne den Client berühren zu müssen.