Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
van toepassing op:
SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceSQL-database in Microsoft Fabric
In dit artikel worden de voordelen en beperkingen van het XML-gegevenstype in SQL Server besproken en kunt u kiezen hoe u XML-gegevens opslaat.
Relationeel-gegevensmodel of XML-gegevensmodel
Als uw gegevens zeer gestructureerd zijn met een bekend schema, werkt het relationele model waarschijnlijk het beste voor gegevensopslag. SQL Server biedt de vereiste functionaliteit en hulpprogramma's die u mogelijk nodig hebt. Als de structuur daarentegen semi-gestructureerd of ongestructureerd is, of onbekend, moet u rekening houden met het modelleren van dergelijke gegevens.
XML is een goede keuze als u een platformonafhankelijk model wilt om de gegevens overdraagbaarheid te garanderen met behulp van structurele en semantische markeringen. Daarnaast is het een geschikte optie als aan een aantal van de volgende eigenschappen wordt voldaan:
Uw gegevens zijn sparse of u weet de structuur van de gegevens niet of de structuur van uw gegevens kan in de toekomst aanzienlijk veranderen.
Uw gegevens vertegenwoordigen insluitingshiërarchie, in plaats van verwijzingen tussen entiteiten en kunnen recursief zijn.
De ordening is een inherente eigenschap van uw gegevens.
U wilt query's uitvoeren op de gegevens of delen ervan bijwerken op basis van de structuur.
Als aan geen van deze voorwaarden wordt voldaan, moet u het relationele gegevensmodel gebruiken. Als uw gegevens bijvoorbeeld de XML-indeling hebben, maar uw toepassing alleen de database gebruikt om de gegevens op te slaan en op te halen, is een kolom [n]varchar(max) alles wat u nodig hebt. Het opslaan van de gegevens in een XML-kolom heeft extra voordelen. De engine zorgt ervoor dat de gegevens correct zijn opgemaakt of geldig zijn en biedt ook ondersteuning voor gedetailleerde query's en updates in de XML-gegevens.
Redenen voor het opslaan van XML-gegevens in SQL Server
Hier volgen enkele van de redenen voor het gebruik van systeemeigen XML-functies in SQL Server in plaats van uw XML-gegevens in het bestandssysteem te beheren:
U wilt uw XML-gegevens op een efficiënte en transacteerde manier delen, opvragen en wijzigen. Fijnmazige gegevenstoegang is belangrijk voor uw toepassing. U kunt bijvoorbeeld een aantal secties in een XML-document extraheren of een nieuwe sectie invoegen zonder het hele document te vervangen.
U hebt relationele gegevens en XML-gegevens en u wilt interoperabiliteit tussen zowel relationele als XML-gegevens in uw toepassing.
U hebt taalondersteuning nodig voor het wijzigen van query's en gegevens voor toepassingen tussen domeinen.
U wilt dat de server garandeert dat de gegevens goed zijn opgemaakt en optioneel uw gegevens valideren op basis van XML-schema's.
U wilt XML-gegevens indexeren voor efficiënte queryverwerking en goede schaalbaarheid, en gebruik maken van een eersteklas queryoptimizer.
U wilt SOAP, ADO.NET en OLE DB-toegang tot XML-gegevens.
U wilt beheerfunctionaliteit van de databaseserver gebruiken voor het beheren van uw XML-gegevens. Dit is bijvoorbeeld back-up, herstel en replicatie.
Als aan geen van deze voorwaarden wordt voldaan, is het wellicht beter om uw gegevens op te slaan als een niet-XML-, groot objecttype, zoals [n]varchar(max) of varbinary(max).
OPTIES voor XML-opslag
De opslagopties voor XML in SQL Server zijn onder andere:
Systeemeigen opslag als XML-gegevenstype
De gegevens worden opgeslagen in een interne weergave die de XML-inhoud van de gegevens behoudt. Deze interne weergave bevat informatie over de insluitingshiërarchie, documentvolgorde en element- en kenmerkwaarden. In het bijzonder blijft de InfoSet-inhoud van de XML-gegevens behouden. Ga voor meer informatie over InfoSet naar http://www.w3.org/TR/xml-infoset. De InfoSet-inhoud is mogelijk geen identieke kopie van de tekst-XML, omdat de volgende informatie niet wordt bewaard: onbelangrijke witruimten, volgorde van kenmerken, naamruimtevoorvoegsels en XML-declaratie.
Voor getypt xml-gegevenstype voegt een XML-gegevenstype dat is gebonden aan XML-schema's, de Post-schemavalidatie InfoSet (PSVI) typegegevens toe aan de InfoSet en wordt gecodeerd in de interne weergave. Dit verbetert de parseringssnelheid aanzienlijk. Zie de W3C XML-schemaspecificaties op http://www.w3.org/TR/xmlschema-1 en http://www.w3.org/TR/xmlschema-2voor meer informatie.
Koppeling tussen XML en relationele opslag
Door een geannoteerd schema (AXSD) te gebruiken, wordt de XML opgesplitst in kolommen in een of meer tabellen. Dit behoudt de betrouwbaarheid van de gegevens op relationeel niveau. Als gevolg hiervan blijft de hiërarchische structuur behouden, hoewel de volgorde tussen elementen wordt genegeerd. Het schema kan niet recursief zijn.
Grote objectopslag, [n]varchar(max) en varbinary(max)
Er wordt een identieke kopie van de gegevens opgeslagen. Dit is handig voor toepassingen met speciale doeleinden, zoals juridische documenten. De meeste toepassingen hebben geen exacte kopie nodig en zijn tevreden met de XML-inhoud (InfoSet fidelity).
Over het algemeen moet u mogelijk een combinatie van deze benaderingen gebruiken. U kunt bijvoorbeeld uw XML-gegevens opslaan in een kolom van het XML-gegevenstype en eigenschappen ervan promoveren naar relationele kolommen. U kunt ook toewijzingstechnologie gebruiken om niet-recursieve delen op te slaan in niet-XML-kolommen en alleen de recursieve xml delen in xml-gegevenstype kolommen.
Keuze van XML-technologie
De keuze van XML-technologie, systeemeigen XML- versus XML-weergave, is doorgaans afhankelijk van de volgende factoren:
Opslagopties
Uw XML-gegevens zijn mogelijk geschikter voor grote objectopslag (bijvoorbeeld een producthandleiding) of meer geschikt voor opslag in relationele kolommen (bijvoorbeeld een regelitem dat is geconverteerd naar XML). Elke opslagoptie behoudt de kwaliteit van documenten in een andere mate.
Querymogelijkheden
Mogelijk vindt u een opslagoptie die meer geschikt is dan een andere, op basis van de aard van uw query's en voor de mate waarin u query's uitvoert op uw XML-gegevens. Gedetailleerde query's van uw XML-gegevens, bijvoorbeeld evaluatie van predicaat op XML-knooppunten, worden ondersteund in verschillende mate in de twee opslagopties.
XML-gegevens indexeren
U kunt de XML-gegevens indexeren om de prestaties van XML-query's te versnellen. Indexeringsopties variëren met de opslagopties; u moet de juiste keuze maken om uw workload te optimaliseren.
Mogelijkheden voor gegevenswijziging
Sommige workloads hebben betrekking op fijnmazige wijzigingen van XML-gegevens. Dit kan bijvoorbeeld het toevoegen van een nieuwe sectie in een document zijn, terwijl andere werkbelastingen, zoals webinhoud, dat niet doen. Taalondersteuning voor gegevenswijziging is mogelijk belangrijk voor uw toepassing.
Schemaondersteuning
Uw XML-gegevens kunnen worden beschreven door een schema dat al dan niet een XML-schemadocument is. De ondersteuning voor schemagebonden XML is afhankelijk van de XML-technologie.
Verschillende keuzes hebben ook verschillende prestatiekenmerken.
Systeemeigen XML-opslag
U kunt uw XML-gegevens opslaan in een xml-gegevenstypekolom op de server. Dit is een geschikte keuze als het volgende van toepassing is:
U wilt een eenvoudige manier om uw XML-gegevens op de server op te slaan en tegelijkertijd documentvolgorde en documentstructuur behouden.
Mogelijk hebt u al dan niet een schema voor uw XML-gegevens.
U wilt uw XML-gegevens opvragen en wijzigen.
U wilt de XML-gegevens indexeren voor snellere verwerking van query's.
Uw toepassing heeft systeemcatalogusweergaven nodig om uw XML-gegevens en XML-schema's te beheren.
Systeemeigen XML-opslag is handig wanneer u XML-documenten hebt met een reeks structuren of als u XML-documenten hebt die voldoen aan verschillende of complexe schema's die te moeilijk zijn om toe te wijzen aan relationele structuren.
Voorbeeld: XML-gegevens modelleren met behulp van het XML-gegevenstype
Overweeg een producthandleiding in XML-indeling die bestaat uit een afzonderlijk hoofdstuk voor elk onderwerp en die meerdere secties in elk hoofdstuk bevat. Een sectie kan subsecties bevatten. Als gevolg hiervan <section> is een recursief element. Producthandleidingen bevatten een grote hoeveelheid gemengde inhoud, diagrammen en technisch materiaal; de gegevens semi-gestructureerd zijn. Gebruikers kunnen een contextuele zoekopdracht uitvoeren naar interessante onderwerpen, zoals het zoeken naar de sectie 'geclusterde index' in het hoofdstuk over 'indexeren' en het uitvoeren van query's op technische hoeveelheden.
Een geschikt opslagmodel voor uw XML-documenten is een kolom met xml-gegevenstypen . Hiermee blijft de InfoSet-inhoud van uw XML-gegevens behouden. Het indexeren van de XML-kolom levert queryprestaties op.
Voorbeeld: Exacte kopieën van XML-gegevens behouden
In de afbeelding wordt ervan uitgegaan dat u volgens overheidsvoorschriften exacte tekstuele kopieën van uw XML-documenten moet bewaren. Dit kunnen bijvoorbeeld ondertekende documenten, juridische documenten of aandelentransactieorders zijn. Het kan zijn dat u uw documenten wilt opslaan in een [n]varchar(max)-kolom.
Voor het uitvoeren van query's converteert u de gegevens naar een XML-gegevenstype en voert u XQuery erop uit. De runtimeconversie kan kostbaar zijn, met name wanneer het document groot is. Als u regelmatig query's uitvoert, kunt u de documenten redundant opslaan in een xml-gegevenstypekolom en deze indexeren terwijl u exacte documentkopieën uit de kolom [n]varchar(max) retourneert.
De XML-kolom kan een berekende kolom zijn, op basis van de kolom [n]varchar(max). U kunt echter geen XML-index maken op een berekende XML-kolom, noch kan er een XML-index worden gebouwd op [n]varchar(max) of varbinary(max)-kolommen.
XML-weergavetechnologie
Door een toewijzing tussen uw XML-schema's en de tabellen in een database te definiëren, maakt u een XML-weergave van uw permanente gegevens. XML-bulksgewijs laden kan worden gebruikt voor het vullen van de onderliggende tabellen met behulp van de XML-weergave. U kunt een query uitvoeren op de XML-weergave met behulp van XPath versie 1.0; de query wordt vertaald naar SQL-query's in de tabellen. Op dezelfde manier worden updates ook doorgegeven aan deze tabellen.
Deze technologie is handig in de volgende situaties:
U wilt een XML-gericht programmeermodel hebben met behulp van XML-weergaven over uw bestaande relationele gegevens.
U hebt een schema (XSD, XDR) voor uw XML-gegevens die een externe partner mogelijk heeft opgegeven.
Volgorde is niet belangrijk in uw gegevens of uw querytabelgegevens zijn niet recursief of de maximale recursiediepte van tevoren bekend.
U wilt de gegevens opvragen en wijzigen via de XML-weergave met behulp van XPath versie 1.0.
U wilt XML-gegevens bulksgewijs laden en deze opsplitsen in de onderliggende tabellen met behulp van de XML-weergave.
Voorbeelden hiervan zijn relationele gegevens die worden weergegeven als XML voor gegevensuitwisseling en webservices en XML-gegevens met een vast schema. Voor meer informatie.
Voorbeeld: Gegevens modelleren met behulp van een geannoteerd XML-schema (AXSD)
Stel dat u bestaande relationele gegevens hebt, zoals klanten, orders en regelitems, die u als XML wilt verwerken. Definieer een XML-weergave met AXSD over de relationele gegevens. Met de XML-weergave kunt u XML-gegevens bulksgewijs laden in uw tabellen en de relationele gegevens opvragen en bijwerken met behulp van de XML-weergave. Dit model is handig als u gegevens moet uitwisselen die XML-markeringen bevatten met andere toepassingen terwijl uw SQL-toepassingen ononderbroken werken.
Hybride model
Vaak is een combinatie van relationele en XML-gegevenstypekolommen geschikt voor gegevensmodellering. Sommige van de waarden uit uw XML-gegevens kunnen worden opgeslagen in relationele kolommen, en de rest, of de hele XML-waarde die is opgeslagen in een XML-kolom. Dit kan leiden tot betere prestaties omdat u meer controle hebt over de indexen die zijn gemaakt op de relationele kolommen en vergrendelingskenmerken.
De waarden die in relationele kolommen moeten worden opgeslagen, zijn afhankelijk van uw workload. Als u bijvoorbeeld alle XML-waarden ophaalt op basis van de padexpressie, /Customer/@CustIdkan het bevorderen van de waarde van het CustId kenmerk in een relationele kolom en het indexeren ervan sneller queryprestaties opleveren. Als uw XML-gegevens daarentegen uitgebreid en niet-uitgevouwen zijn in relationele kolommen, kunnen de kosten voor opnieuw verzamelen aanzienlijk zijn.
Voor zeer gestructureerde XML-gegevens is bijvoorbeeld de inhoud van een tabel geconverteerd naar XML; u kunt alle waarden toewijzen aan relationele kolommen en mogelijk xml-weergavetechnologie gebruiken.
Granulariteit van XML-gegevens
De granulariteit van de XML-gegevens die zijn opgeslagen in een XML-kolom is belangrijk voor het vergrendelen en in mindere mate is het ook belangrijk voor updates. SQL Server maakt gebruik van hetzelfde vergrendelingsmechanisme voor zowel XML- als niet-XML-gegevens. Daarom zorgt vergrendeling op rijniveau ervoor dat alle XML-exemplaren in de rij worden vergrendeld. Wanneer de granulariteit groot is, zorgt het vergrendelen van grote XML-exemplaren voor updates ervoor dat doorvoer in een scenario met meerdere gebruikers afneemt. Aan de andere kant verliest ernstige decompositie objectencapsulatie en verhoogt de kosten van herassemblage.
Een balans tussen de vereisten voor gegevensmodellering en het vergrendelen en bijwerken van kenmerken is belangrijk voor een goed ontwerp. In SQL Server is de grootte van de werkelijke opgeslagen XML-exemplaren echter niet zo kritiek.
Updates van een XML-exemplaar worden bijvoorbeeld uitgevoerd met behulp van nieuwe ondersteuning voor gedeeltelijke binaire grote objecten (BLOB) en gedeeltelijke indexupdates waarin het bestaande opgeslagen XML-exemplaar wordt vergeleken met de bijgewerkte versie. Bijwerken van gedeeltelijk binair groot object (BLOB) voert een differentiële vergelijking uit tussen de twee XML-exemplaren en werkt alleen de verschillen bij. Gedeeltelijke indexupdates wijzigen alleen de rijen die moeten worden gewijzigd in de XML-index.
Beperkingen van het xml-gegevenstype
Let op de volgende algemene beperkingen die van toepassing zijn op het xml-gegevenstype :
De opgeslagen weergave van xml-gegevenstype-exemplaren mag niet groter zijn dan 2 GB.
Het kan niet worden gebruikt als subtype van een sql_variant exemplaar.
Er wordt geen ondersteuning geboden voor casting of conversie naar tekst of ntext. Gebruik in plaats daarvan varchar(max) of nvarchar(max).
Het kan niet worden vergeleken of gesorteerd. Dit betekent dat een XML-gegevenstype niet kan worden gebruikt in een GROUP BY-instructie .
Het kan niet worden gebruikt als parameter voor scalaire, ingebouwde functies dan ISNULL, COALESCE en DATALENGTH.
Het kan niet worden gebruikt als een sleutelkolom in een index. Het kan echter worden opgenomen als gegevens in een geclusterde index of expliciet worden toegevoegd aan een niet-geclusterde index met behulp van het sleutelwoord INCLUDE wanneer de niet-geclusterde index wordt gemaakt.
XML-elementen kunnen tot maximaal 128 niveaus genest worden.