Dela via

xml-datatyp och kolumner (SQL Server)

Gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceSQL-databas i Microsoft Fabric

Den här artikeln beskriver fördelarna och begränsningarna för XML-datatypen i SQL Server och hjälper dig att välja hur XML-data ska lagras.

Relations- eller XML-datamodell

Om dina data är mycket strukturerade med ett känt schema fungerar relationsmodellen förmodligen bäst för datalagring. SQL Server tillhandahåller de funktioner och verktyg som krävs. Å andra sidan, om strukturen är halvstrukturerad eller ostrukturerad, eller okänd, måste du överväga att modellera sådana data.

XML är ett bra val om du vill ha en plattformsoberoende modell för att säkerställa dataportabilitet med hjälp av strukturell och semantisk markering. Dessutom är det ett lämpligt alternativ om några av följande egenskaper är uppfyllda:

  • Dina data är glesa eller så känner du inte till datastrukturen, eller så kan strukturen för dina data ändras avsevärt i framtiden.

  • Dina data representerar inneslutningshierarkin i stället för referenser mellan entiteter och kan vara rekursiva.

  • Ordningen är inbyggd i dina data.

  • Du vill fråga efter data eller uppdatera delar av dem baserat på dess struktur.

Om inget av dessa villkor uppfylls bör du använda relationsdatamodellen. Om dina data till exempel är i XML-format men programmet bara använder databasen för att lagra och hämta data, är en [n]varchar(max) kolumn allt du behöver. Att lagra data i en XML-kolumn har ytterligare fördelar. Detta inkluderar att låta motorn fastställa att data är välformulerade eller giltiga, och inkluderar även stöd för detaljerade frågor och uppdateringar i XML-data.

Orsaker till lagring av XML-data i SQL Server

Följande är några av anledningarna till att använda interna XML-funktioner i SQL Server i stället för att hantera DINA XML-data i filsystemet:

  • Du vill dela, fråga och ändra XML-data på ett effektivt och transaktionellt sätt. Detaljerad dataåtkomst är viktig för ditt program. Du kanske till exempel vill extrahera några av avsnitten i ett XML-dokument, eller så kanske du vill infoga ett nytt avsnitt utan att ersätta hela dokumentet.

  • Du har relationsdata och XML-data och vill ha samverkan mellan både relations- och XML-data i ditt program.

  • Du behöver språkstöd för fråge- och dataändring för program mellan domäner.

  • Du vill att servern ska garantera att data är välformulerade och även validera dina data enligt XML-scheman.

  • Du vill indexera XML-data för effektiv frågebearbetning och bra skalbarhet och användning av en förstklassig frågeoptimerare.

  • Du vill ha SOAP-, ADO.NET- och OLE DB-åtkomst till XML-data.

  • Du vill använda administrativa funktioner på databasservern för att hantera DINA XML-data. Detta skulle till exempel vara säkerhetskopiering, återställning och replikering.

Om inget av dessa villkor uppfylls kan det vara bättre att lagra dina data som en icke-XML- eller stor objekttyp, till exempel [n]varchar(max) eller varbinary(max).

XML-lagringsalternativ

Lagringsalternativen för XML i SQL Server innehåller följande:

  • Intern lagring som XML-datatyp

    Data lagras i en intern representation som bevarar XML-innehållet i data. Den här interna representationen innehåller information om inneslutningshierarkin, dokumentordningen och element- och attributvärdena. Mer specifikt bevaras InfoSet-innehållet i XML-data. Mer information om InfoSet finns i http://www.w3.org/TR/xml-infoset. InfoSet-innehållet kanske inte är en identisk kopia av text-XML eftersom följande information inte behålls: obetydliga blanksteg, attributordning, namnområdesprefix och XML-deklaration.

    För typen xml-datatyp, en xml-datatyp som är bunden till XML-scheman, lägger PSVI (Post-Schema Validation InfoSet) till typinformation i InfoSet och kodas i den interna representationen. Detta förbättrar parsningshastigheten avsevärt. Mer information finns i W3C XML-schemaspecifikationerna på http://www.w3.org/TR/xmlschema-1 och http://www.w3.org/TR/xmlschema-2.

  • Mappning mellan XML och relationslagring

    Med hjälp av ett kommenterat schema (AXSD) delas XML-koden upp i kolumner i en eller flera tabeller. Detta bevarar noggrannheten av data på relationsnivå. Därför bevaras den hierarkiska strukturen även om ordningen mellan element ignoreras. Schemat kan inte vara rekursivt.

  • Stor objektlagring, [n]varchar(max) och varbinary(max)

    En identisk kopia av data lagras. Detta är användbart för särskilda program, till exempel juridiska dokument. De flesta program kräver ingen exakt kopia och är nöjda med XML-innehållet (InfoSet-återgivning).

I allmänhet kan du behöva använda en kombination av dessa metoder. Du kanske till exempel vill lagra DINA XML-data i en XML-datatypskolumn och flytta upp egenskaper från dem till relationskolumner. Eller så kanske du vill använda mappningsteknik för att lagra icke-rekursiva delar i icke-XML-kolumner och endast rekursiva delar i xml-datatypskolumner.

Val av XML-teknik

Valet av XML-teknik, intern XML jämfört med XML-vy, beror vanligtvis på följande faktorer:

  • Lagringsalternativ

    Dina XML-data kan vara lämpligare för lagring av stora objekt (till exempel en produkthandbok) eller mer lagringsbara i relationskolumner (till exempel ett radobjekt som konverterats till XML). Varje lagringsalternativ bevarar dokumenttrohet i olika utsträckning.

  • Frågefunktioner

    Du kan hitta ett lagringsalternativ som är lämpligare än ett annat, baserat på typen av frågor och i vilken utsträckning du frågar dina XML-data. Detaljerad fråga om dina XML-data, till exempel predikatutvärdering på XML-noder, stöds i varierande grad i de två lagringsalternativen.

  • Indexera XML-data

    Du kanske vill indexering av XML-data för att påskynda XML-frågeprestanda. Indexeringsalternativen varierar beroende på lagringsalternativen. du måste göra rätt val för att optimera din arbetsbelastning.

  • Funktioner för dataändring

    Vissa arbetsbelastningar omfattar detaljerad ändring av XML-data. Detta kan till exempel omfatta att lägga till ett nytt avsnitt i ett dokument, medan andra arbetsbelastningar, till exempel webbinnehåll, inte gör det. Språkstöd för datamodifiering kan vara viktigt för ditt program.

  • Schemastöd

    Dina XML-data kan beskrivas av ett schema som kanske eller kanske inte är ett XML-schemadokument. Stödet för schemabunden XML beror på XML-tekniken.

Olika alternativ har också olika prestandaegenskaper.

Inbyggd XML-lagring

Du kan lagra DINA XML-data i en xml-datatypkolumn på servern. Detta är ett lämpligt val om följande gäller:

  • Du vill ha ett enkelt sätt att lagra DINA XML-data på servern och samtidigt bevara dokumentordningen och dokumentstrukturen.

  • Du kanske eller kanske inte har ett schema för dina XML-data.

  • Du vill fråga och ändra dina XML-data.

  • Du vill indexering av XML-data för snabbare frågebearbetning.

  • Programmet behöver systemkatalogvyer för att administrera XML-data och XML-scheman.

Intern XML-lagring är användbart när du har XML-dokument som har ett antal strukturer, eller om du har XML-dokument som överensstämmer med olika eller komplexa scheman som är för svåra att mappa till relationsstrukturer.

Exempel: Modellera XML-data med xml-datatypen

Överväg en produkthandbok i XML-format som består av ett separat kapitel för varje ämne och som har flera avsnitt i varje kapitel. Ett avsnitt kan innehålla underavsnitt. Därför <section> är ett rekursivt element. Produkthandböcker innehåller en stor mängd blandat innehåll, diagram och tekniskt material. data är halvstrukturerade. Användare kanske vill utföra en sammanhangsberoende sökning efter ämnen av intresse, till exempel söka efter avsnittet om "klustrat index" i kapitlet om "indexering" och fråga tekniska kvantiteter.

En lämplig lagringsmodell för DINA XML-dokument är en xml-datatypkolumn . Detta bevarar InfoSet-innehållet i dina XML-data. Indexering av XML-kolumnen gynnar frågeprestanda.

Exempel: Behåll exakta kopior av XML-data

Anta som illustration att myndighetsbestämmelser kräver att du behåller exakta textkopior av dina XML-dokument. Dessa kan till exempel omfatta signerade dokument, juridiska dokument eller lagertransaktionsbeställningar. Du kanske vill lagra dina dokument i en [n]varchar(max) -kolumn.

För förfrågningar konverterar du data till xml-datatypen under körning och kör XQuery på den. Konverteringen kan vara kostsamt, särskilt när dokumentet är stort. Om du frågar ofta kan du redundant lagra dokumenten i en xml-datatypkolumn och indexera dem medan du returnerar exakta dokumentkopior från kolumnen [n]varchar(max).

XML-kolumnen kan vara en beräknad kolumn baserat på kolumnen [n]varchar(max). Du kan dock inte skapa ett XML-index på en beräknad XML-kolumn, och du kan inte heller bygga ett XML-index på [n]varchar(max) eller varbinary(max).

XML-vyteknik

Genom att definiera en mappning mellan dina XML-scheman och tabellerna i en databas skapar du en XML-vy över dina beständiga data. Xml-massinläsning kan användas för att fylla i de underliggande tabellerna med hjälp av XML-vyn. Du kan köra frågor mot XML-vyn med hjälp av XPath version 1.0. frågan översätts till SQL-frågor i tabellerna. På samma sätt sprids även uppdateringar till dessa tabeller.

Den här tekniken är användbar i följande situationer:

  • Du vill ha en XML-centrerad programmeringsmodell med hjälp av XML-vyer över dina befintliga relationsdata.

  • Du har ett schema (XSD, XDR) för dina XML-data som en extern partner kan ha angett.

  • Ordningen är inte viktig i dina data, eller så är frågetabelldata inte rekursiva, eller så är det maximala rekursionsdjupet känt i förväg.

  • Du vill köra frågor mot och ändra data via XML-vyn med hjälp av XPath version 1.0.

  • Du vill massinläsa XML-data och dela upp dem i de underliggande tabellerna med hjälp av XML-vyn.

Exempel är relationsdata som exponeras som XML för datautbyte och webbtjänster samt XML-data med fast schema. För mer information.

Exempel: Modellera data med ett kommenterat XML-schema (AXSD)

Anta som illustration att du har befintliga relationsdata, till exempel kunder, beställningar och radobjekt, som du vill hantera som XML. Definiera en XML-vy med hjälp av AXSD över relationsdata. Med XML-vyn kan du massinläsa XML-data i dina tabeller och köra frågor mot och uppdatera relationsdata med hjälp av XML-vyn. Den här modellen är användbar om du behöver utbyta data som innehåller XML-kod med andra program medan DINA SQL-program fungerar oavbrutet.

Hybridmodell

Ofta är en kombination av kolumner av relations- och XML-datatyp lämplig för datamodellering. Vissa av värdena från DINA XML-data kan lagras i relationskolumner och resten eller hela XML-värdet som lagras i en XML-kolumn. Detta kan ge bättre prestanda eftersom du har mer kontroll över indexen som skapats för relationskolumnerna och låsningsegenskaperna.

Vilka värden som ska lagras i relationskolumner beror på din arbetsbelastning. Om du till exempel hämtar alla XML-värden baserat på sökvägsuttrycket /Customer/@CustIdkan det ge snabbare frågeprestanda om du befordrar attributets CustId värde till en relationskolumn och indexering. Å andra sidan, om din XML-data i stor utsträckning och icke-redundant bryts ned i relationskolumner, kan återsamlingskostnaden vara betydande.

För mycket strukturerade XML-data har till exempel innehållet i en tabell konverterats till XML. du kan mappa alla värden till relationskolumner och eventuellt använda XML-vyteknik.

Kornighet för XML-data

Kornigheten för XML-data som lagras i en XML-kolumn är viktig för låsning, och i mindre utsträckning är det också viktigt för uppdateringar. SQL Server använder samma låsmekanism för både XML- och icke-XML-data. Därför gör låsning på radnivå att alla XML-instanser på raden låses. När kornigheten är stor leder låsning av stora XML-instanser för uppdateringar till att dataflödet minskar i ett scenario med flera användare. Å andra sidan förlorar allvarlig nedbrytning objektkapsling och ökar återmonteringskostnaden.

En balans mellan datamodelleringskrav och låsnings- och uppdateringsegenskaper är viktig för en bra design. I SQL Server är dock storleken på faktiska lagrade XML-instanser inte lika kritisk.

Till exempel utförs uppdateringar av en XML-instans med nytt stöd för partiella binära stora objekt (BLOB) och partiella indexuppdateringar där den befintliga lagrade XML-instansen jämförs med den uppdaterade versionen. Blob-uppdateringen (Partial Binary Large Object) utför en differentiell jämförelse mellan de två XML-instanserna och uppdaterar endast skillnaderna. Partiella indexuppdateringar ändrar endast de rader som måste ändras i XML-indexet.

Begränsningar för xml-datatypen

Observera följande allmänna begränsningar som gäller för xml-datatypen :

  • Den lagrade representationen av xml-datatypsinstanser får inte överstiga 2 GB.

  • Det kan inte användas som en undertyp av en sql_variant instans.

  • Den stöder inte gjutning eller konvertering till text eller ntext. Använd varchar(max) eller nvarchar(max) i stället.

  • Det kan inte jämföras eller sorteras. Det innebär att en XML-datatyp inte kan användas i en GROUP BY-instruktion .

  • Det kan inte användas som en parameter för skalära, inbyggda funktioner förutom ISNULL, COALESCE och DATALENGTH.

  • Det kan inte användas som en nyckelkolumn i ett index. Den kan dock inkluderas som data i ett grupperat index eller uttryckligen läggas till i ett icke-grupperat index med nyckelordet INCLUDE när det icke-grupperade indexet skapas.

  • XML-element kan kapslas upp till 128 nivåer.

Se även

  • Last updated on