XML-Datentyp und -Spalten (SQL Server)

Gilt für:SQL ServerAzure SQL-DatenbankAzure SQL Managed Instance

In diesem Artikel werden die Vorteile und die Einschränkungen des XML-Datentyps in SQL Server erläutert, und Sie können auswählen, wie XML-Daten gespeichert werden sollen.

Relationales oder XML-Datenmodell

Wenn Ihre Daten mit einem bekannten Schema stark strukturiert sind, funktioniert das relationale Modell wahrscheinlich am besten für die Datenspeicherung. SQL Server stellt die erforderlichen Funktionen und Tools bereit, die Sie möglicherweise benötigen. Wenn Ihre Daten dagegen halbstrukturiert oder nicht strukturiert sind oder ihre Struktur unbekannt ist, müssen Sie das Modellieren dieser Daten in Erwägung ziehen.

XML ist eine gute Wahl, wenn Sie ein plattformunabhängiges Modell anstreben, um die Übertragbarkeit der Daten durch Verwendung von strukturellen und semantischen Markups sicherzustellen. XML ist darüber hinaus eine geeignete Option, wenn einige der folgenden Eigenschaften erfüllt sind:

• Ihre Daten sind gering, oder Sie kennen die Struktur der Daten nicht, oder die Struktur Ihrer Daten kann sich in Zukunft erheblich ändern.

• Ihre Daten stellen keine Verweise zwischen Entitäten dar, sondern entsprechen einer Einkapselungshierarchie, die auch rekursiv sein kann.

• Ihre Daten weisen eine inhärente Reihenfolge auf.

• Sie wollen basierend auf der Struktur Ihrer Daten Abfragen in den Daten ausführen oder Teile der Daten aktualisieren.

Wenn keine dieser Bedingungen zutrifft, sollten Sie das relationale Datenmodell verwenden. Wenn die Daten z.B. im XML-Format vorliegen, die Anwendung die Datenbank jedoch ausschließlich zum Speichern und Abrufen der Daten verwendet, benötigen Sie lediglich eine [n]varchar(max) -Spalte. Das Speichern der Daten in einer XML-Spalte bietet weitere Vorteile. Beispielsweise kann mit der Engine ermittelt werden, ob die Daten wohlgeformt oder gültig sind, und es werden auch differenzierte Abfragen und Updates der XML-Daten unterstützt.

Gründe für das Speichern von XML-Daten in SQL Server

Im Folgenden finden Sie einige Gründe für die Verwendung systemeigener XML-Features in SQL Server, anstatt Ihre XML-Daten im Dateisystem zu verwalten:

• Sie wollen Ihre XML-Daten auf effiziente und transaktive Weise freigeben, abfragen und ändern. Ein differenzierter Datenzugriff ist für Ihre Anwendung sehr wichtig. Sie wollen z. B. einige der Abschnitte innerhalb eines XML-Dokuments extrahieren, oder Sie wollen einen neuen Abschnitt einfügen, ohne Ihr gesamtes Dokument ersetzen zu müssen.

• Sie verfügen über relationale Daten und XML-Daten und wollen innerhalb Ihrer Anwendung die Interoperabilität zwischen den relationalen Daten und den XML-Daten gewährleisten.

• Sie benötigen die Sprachenunterstützung für Abfragen und Möglichkeiten zur Datenänderung für domänenübergreifende Anwendungen.

• Sie wollen vom Server sicherstellen lassen, dass die Daten wohlgeformt sind, und Ihre Daten auch optional gemäß XML-Schemas überprüfen lassen.

• Sie wünschen eine Indizierung von XML-Daten, um ein effizientes Verarbeiten von Abfragen und eine gute Skalierbarkeit zu ermöglichen, und wollen einen erstklassigen Abfrageoptimierer verwenden.

• Sie wünschen den SOAP-, ADO.NET- und OLE DB-Zugriff auf XML-Daten.

• Sie möchten Verwaltungsfunktionen für den Datenbankserver verwenden, um Ihre XML-Daten zu verwalten. Dazu gehören z. B. Sicherung, Wiederherstellung und Replikation der Daten.

Wenn keine dieser Bedingungen zutrifft, kann es besser sein, die Daten in einem Nicht-XML-Datentyp für große Objekte zu speichern, beispielsweise in [n]varchar(max) oder varbinary(max).

XML-Speicheroptionen

Die Speicheroptionen für XML in SQL Server umfassen Folgendes:

• Systemeigenes Speichern als xml -Datentyp

  Die Daten werden in einer internen Darstellung gespeichert, die den XML-Inhalt der Daten beibehält. Diese interne Darstellung umfasst Informationen über die Einkapselungshierarchie, die Dokumentreihenfolge sowie die Element- und Attributwerte. Insbesondere bleibt der InfoSet-Inhalt der XML-Daten erhalten. Weitere Informationen zu InfoSet finden Sie unter http://www.w3.org/TR/xml-infoset. Der InfoSet-Inhalt ist möglicherweise keine identische Kopie der Text-XML, da die folgenden Informationen nicht beibehalten werden: unbedeutete Leerzeichen, Reihenfolge der Attribute, Namespacepräfixe und XML-Deklaration.

  Für den typisierten XML -Datentyp, ein an XML -Schemas gebundener -Datentyp, werden durch das PSVI (Post-Schema Validation InfoSet) dem InfoSet Typinformationen hinzugefügt und in der internen Darstellung codiert. Das führt zu einer erheblichen Steigerung der Analysegeschwindigkeit. Weitere Informationen finden Sie in den W3C-XML-Schemaspezifikationen unter http://www.w3.org/TR/xmlschema-1 und http://www.w3.org/TR/xmlschema-2.

• Zuordnung zwischen XML- und relationaler Speicherung

  Durch Verwenden eines mit Anmerkungen versehenen Schemas (AXSD) wird der XML-Code in Spalten in einer oder mehreren Tabellen zerlegt. Damit bleibt die Genauigkeit der Daten auf der relationalen Ebene erhalten. Das führt dazu, dass die hierarchische Struktur erhalten bleibt, obwohl die Reihenfolge unter den Elementen ignoriert wird. Das Schema kann nicht rekursiv sein.

• Speichern von großen Objekten, [n]varchar(max) und varbinary(max)

  Eine identische Kopie der Daten wird gespeichert. Dies ist nützlich für Anwendungen mit einem besonderen Zweck wie z. B. zum Speichern juristischer Dokumente. Die meisten Anwendungen benötigen keine exakte Kopie und sind mit dem XML-Inhalt (InfoSet Fidelity) zufrieden.

Im Allgemeinen müssen Sie eine Kombination aus diesen beiden Vorgehensweisen verwenden. Sie wollen z. B. die XML-Daten in einer xml -Datentypspalte speichern und Eigenschaften daraus in relationale Spalten heraufstufen. Oder Sie möchten die Zuordnungstechnologie verwenden, um nicht rekursive Teile in Nicht-XML-Spalten und ausschließlich die rekursiven Teile in XML -Datentypspalten zu speichern.

Auswahl der XML-Technologie

Die Auswahl der XML-Technologie – also systemeigene XML oder XML-Sicht – richtet sich im Allgemeinen nach den folgenden Faktoren:

• Speicheroptionen

  Ihre XML-Daten können besser für die Speicherung großer Objekte geeignet sein (z. B. ein Produkthandbuch) oder kommen eher für die Speicherung in relationalen Spalten in Frage (z. B. ein in XML konvertierter Einzelposten). Mit jeder Speicheroption wird die Dokumentgenauigkeit in einem unterschiedlichen Ausmaß beibehalten.

• Abfragemöglichkeiten

  Ausgehend vom Charakter Ihrer Abfragen und vom Ausmaß, in dem Sie Ihre XML-Daten abfragen, erscheint Ihnen möglicherweise eine Speicheroption geeigneter als eine andere. So wird mit den beiden Speicheroptionen die differenzierte Abfrage Ihrer XML-Daten, z. B. die Prädikatauswertung für XML-Knoten, in einem unterschiedlichen Ausmaß unterstützt.

• Indizieren von XML-Daten

  Sie möchten möglicherweise die XML-Daten indizieren, um die Geschwindigkeit der XML-Abfrage zu erhöhen. Die Indexoptionen sind bei den beiden Speicheroptionen unterschiedlich, und Sie müssen die geeignete Auswahl treffen, um Ihre Arbeitsauslastung zu optimieren.

• Möglichkeiten zur Datenänderung

  Bestimmte Arbeitsauslastungen erfordern ein differenziertes Ändern der XML-Daten. Dies kann z. B. das Hinzufügen eines neuen Abschnitts innerhalb eines Dokuments umfassen, während andere Arbeitslasten, z. B. Webinhalte, nicht verwendet werden. Für Ihre Anwendung kann die Sprachenunterstützung bei der Datenänderung wichtig sein.

• Unterstützung von Schemas

  Ihre XML-Daten können durch ein Schema beschrieben sein, bei dem es sich um ein XML-Schemadokument handeln kann oder auch nicht. Die Unterstützung für an Schemas gebundenen XML-Code richtet sich nach der ausgewählten XML-Technologie.

Die verschiedenen Auswahlmöglichkeiten sind auch mit unterschiedlichen Leistungsmerkmalen verbunden.

Nativer XML-Speicher

Sie können die XML-Daten einer xml -Datentypspalte auf dem Server speichern. Dies ist eine geeignete Option, wenn folgende Aussagen zutreffen:

• Sie benötigen eine einfache Methode zum Speichern Ihrer XML-Daten auf dem Server und wollen gleichzeitig die Dokumentreihenfolge und die Dokumentstruktur beibehalten.

• Für Ihre XML-Daten kann ein Schema vorhanden sein, was aber nicht unbedingt der Fall sein muss.

• Sie wollen Ihre XML-Daten abfragen und bearbeiten.

• Sie wollen die XML-Daten indizieren, um die Abfrageverarbeitung zu beschleunigen.

• Ihre Anwendung benötigt Systemkatalogsichten zum Verwalten Ihrer XML-Daten und XML-Schemas.

Die systemeigene XML-Speicherung ist nützlich, wenn Sie über XML-Dokumente mit vielfältigen Strukturen verfügen oder wenn Sie über XML-Dokumente verfügen, die verschiedenen oder komplexen Schemas entsprechen, sodass sie keinen relationalen Strukturen zugeordnet werden können.

Beispiel: Modellieren von XML-Daten mithilfe des XML-Datentyps

Stellen wir uns ein Produkthandbuch im XML-Format vor, das aus einem getrennten Kapitel für jedes Thema besteht und bei dem jedes Kapitel wiederum mehrere Abschnitte umfasst. Ein Abschnitt kann jeweils Unterabschnitte enthalten. Deshalb ist <section> ein rekursives Element. Produkthandbücher enthalten eine riesige Menge gemischter Inhalte, Diagramme und technischer Materialien; die Daten sind deshalb halbstrukturiert. Benutzer wollen möglicherweise eine Kontextsuche nach Themen von Interesse durchführen. So könnten sie z. B. nach dem Abschnitt zum Thema "gruppierter Index" innerhalb des Kapitels zum Thema "Indizieren" suchen und technische Mengen abfragen.

Ein geeignetes Speichermodell für die XML-Dokumente ist eine xml -Datentypspalte. Dabei bleibt der InfoSet-Inhalt Ihrer XML-Daten erhalten. Durch Indizieren der XML-Spalte wird die Abfrageleistung gesteigert.

Beispiel: Beibehalten exakter Kopien von XML-Daten

Nehmen wir zur Veranschaulichung an, dass Sie durch gesetzliche Bestimmungen dazu verpflichtet sind, exakte Textkopien Ihrer XML-Dokumente beizubehalten. Bei diesen Dokumenten könnte es sich z. B. um unterschriebene Dokumente, juristisch relevante Dokumente oder Unterlagen zu Börsengeschäften handeln. Möglicherweise möchten Sie anschließend die Dokumente in einer [n]varchar(max) -Spalte speichern.

Konvertieren Sie zum Abfragen die Daten zur Laufzeit in xml-Datentyp , und führen Sie XQuery darauf aus. Die Konvertierung zur Laufzeit kann jedoch teuer sein, insbesondere wenn es sich um ein großes Dokument handelt. Wenn Sie häufig Abfragen ausführen, können Sie die Dokumente redundant in einer XML -Datentypspalte speichern und diese indizieren, während Sie genaue Dokumentkopien aus der [n]varchar(max) -Spalte zurückgeben.

Bei der XML-Spalte kann es sich um eine berechnete Spalte handeln, basierend auf der [n]varchar(max) -Spalte. Sie können jedoch keinen XML-Index für eine berechnete XML-Spalte erstellen oder einen XML-Index auf [n]varchar(max) oder varbinary(max) -Spalten erstellen.

XML-Ansichtstechnologie

Indem Sie eine Zuordnung zwischen Ihren XML-Schemas und den Tabellen in einer Datenbank definieren, erstellen Sie eine XML-Ansicht Ihrer persistenten Daten. Mithilfe von XML-Massenladen können die zugrunde liegenden Tabellen anhand der XML-Sicht aufgefüllt werden. Sie können die XML-Sicht mithilfe von XPath Version 1.0 abfragen; die Abfrage wird in SQL-Abfragen für die Tabellen übersetzt. In gleicher Weise werden auch Updates an diese Tabellen weitergegeben.

Diese Technologie kann in folgenden Situationen nützlich sein:

• Sie benötigen ein XML-zentriertes Programmierungsmodell mit Verwendung von XML-Sichten für Ihre vorhandenen relationalen Daten.

• Sie verfügen über ein Schema (XSD, XDR) für Ihre XML-Daten, das eventuell von einem externen Partner stammt.

• Die Reihenfolge ist in Ihren Daten nicht wichtig, oder Die Abfragetabellendaten sind nicht rekursiv, oder die maximale Rekursionstiefe wird im Voraus bekannt.

• Sie wollen die Daten über die XML-Sicht abfragen und bearbeiten, indem Sie XPath Version 1.0 verwenden.

• Sie wollen einen Massenladevorgang für XML-Daten durchführen und diese mithilfe der XML-Sicht in die zugrunde liegenden Tabellen zerlegen.

Zu den Beispielen zählen relationale Daten, die als XML zum Datenaustausch und für Webdienste zugänglich gemacht werden, sowie XML-Daten mit festem Schema. Weitere Informationen

Beispiel: Modellieren von Daten mithilfe eines kommentierten XML-Schemas (AXSD)

Zur Veranschaulichung nehmen wir an, dass Sie über relationale Daten (z. B. zu Kunden, Bestellungen und Einzelposten) verfügen, die Sie als XML handhaben möchten. Definieren Sie eine XML-Sicht, indem Sie AXDS auf die relationalen Daten anwenden. Die XML-Sicht ermöglicht Ihnen, einen Massenladevorgang der XML-Daten in Ihren Tabellen durchzuführen und die relationalen Daten mithilfe der XML-Sicht abzufragen und zu aktualisieren. Dieses Modell ist nützlich, wenn Sie Daten, die XML-Markups enthalten, mit anderen Anwendungen austauschen müssen, während Ihre SQL-Anwendungen ununterbrochen weiterarbeiten.

Hybridmodell

Häufig ist für die Datenmodellierung eine Kombination aus relationalen Spalten und xml -Datentypspalten geeignet. Einige der Werte aus Ihren XML-Daten können in relationalen Spalten gespeichert werden, während der Rest oder der gesamte XML-Wert in einer XML-Spalte gespeichert wird. Das kann zu einer besseren Leistung führen, indem Sie über bessere Steuerungsmöglichkeiten für die Indizes, die für die relationalen Spalten erstellt wurden, und über bessere Sperrenmerkmale verfügen können.

Die Werte, die in relationalen Spalten gespeichert werden sollen, richten sich nach Ihrer Arbeitsauslastung. Wenn Sie z. B. alle XML-Werte basierend auf dem Pfadausdruck abrufen, /Customer/@CustIdwird der Wert des CustId Attributs in eine relationale Spalte höhergeschrieben, und die Indizierung kann zu einer schnelleren Abfrageleistung führen. Wenn Ihre XML-Daten jedoch umfassend und nicht vollständig in relationale Spalten zerlegt werden, kann die Neuassembly-Kosten erheblich sein.

Wurde z. B. für stark strukturierte XML-Daten der Inhalt einer Tabelle in XML konvertiert, können Sie alle Werte relationalen Spalten zuordnen und möglicherweise die XML-Sichttechnologie verwenden.

Granularität von XML-Daten

Die Granularität der in einer XML-Spalte gespeicherten XML-Daten ist wichtig für das Sperren und in geringerem Maße auch für Updates. SQL Server verwendet den gleichen Sperrmechanismus sowohl für XML- als auch für Nicht-XML-Daten. Deshalb führt eine Sperre auf Zeilenebene dazu, dass alle XML-Instanzen in der Zeile gesperrt werden. Bei hoher Granularität führt die Sperre großer XML-Instanzen für Updates in einem Szenario mit mehreren Benutzern zur Verringerung des Datendurchsatzes. Andererseits geht bei starker Dekomposition die Objekteinkapselung verloren, und die Kosten für die Reassemblierung steigen.

Um einen guten Entwurf zu erzielen, muss ein Kompromiss aus den Anforderungen der Datenmodellierung und den Sperren- und Updatemerkmalen gefunden werden. In SQL Server ist die Größe der tatsächlich gespeicherten XML-Instanzen jedoch nicht so wichtig.

Beispielsweise wird für Updates einer XML-Instanz die neue Unterstützung für partielle BLOB- (Binary Large Object) und partielle Indexupdates genutzt, bei denen die vorhandene gespeicherte XML-Instanz mit ihrer aktualisierten Version verglichen wird. Beim BLOB-Update wird ein differenzieller Vergleich zwischen den beiden XML-Instanzen durchgeführt, und es werden nur die Differenzen aktualisiert. Partielle Indexupdates nehmen im XML-Index nur Änderungen an solchen Zeilen vor, die geändert werden müssen.

Einschränkungen des XML-Datentyps

Für den xml -Datentyp gelten die folgenden allgemeinen Einschränkungen:

• Die gespeicherte Darstellung von XML-Datentypinstanzen darf 2 GB nicht überschreiten.

• Sie kann nicht als Untertyp einer sql_variant Instanz verwendet werden.

• Das Umwandeln oder Konvertieren in Text oder ntext wird nicht unterstützt. Verwenden Sie stattdessen varchar(max) oder nvarchar(max) .

• Sie kann nicht verglichen oder sortiert werden. Dies bedeutet, dass ein XML-Datentyp nicht in einer GROUP BY-Anweisung verwendet werden kann.

• Sie kann nicht als Parameter für andere skalare, integrierte Funktionen als ISNULL, COALESCE und DATALENGTH verwendet werden.

• Sie kann nicht als Schlüsselspalte in einem Index verwendet werden. Er kann jedoch als Daten in einen gruppierten Index aufgenommen werden oder über das Schlüsselwort INCLUDE explizit zu einem nicht gruppierten Index hinzugefügt werden, wenn der nicht gruppierte Index erstellt wird.

• XML-Elemente können bis auf 128 Ebenen geschachtelt werden.

Siehe auch

• Beispiele für den Massenimport und -export von XML-Dokumenten (SQL Server)