xml-adattípus és -oszlopok (SQL Server)

A következőkre vonatkozik:SQL ServerAzure SQL DatabaseFelügyelt Azure SQL-példánySQL-adatbázis a Microsoft Fabricben

Ez a cikk az XML-adattípus előnyeit és korlátait ismerteti az SQL Serverben, és segít kiválasztani az XML-adatok tárolásának módját.

Relációs vagy XML-adatmodell

Ha az adatok jól strukturáltak egy ismert sémával, a relációs modell valószínűleg az adattároláshoz fog a legjobban működni. Az SQL Server biztosítja a szükséges funkciókat és eszközöket, amelyekre szüksége lehet. Másrészt, ha a struktúra részben strukturált, strukturálatlan vagy ismeretlen, figyelembe kell vennie az ilyen adatok modellezését.

Az XML akkor jó választás, ha platformfüggetlen modellt szeretne, hogy strukturális és szemantikai korrektúra használatával biztosítsa az adatok hordozhatóságát. Emellett megfelelő lehetőség, ha az alábbi tulajdonságok némelyike teljesül:

  • Az adatok ritkák, vagy nem ismerik az adatok struktúráját, vagy az adatok szerkezete a jövőben jelentősen megváltozhat.

  • Az adatok az entitások közötti hivatkozások helyett az elszigetelési hierarchiát jelölik, és rekurzívak lehetnek.

  • A sorrend az adatokban rejlik.

  • A struktúrája alapján le szeretne kérdezni az adatokba, vagy frissíteni szeretné annak egyes részeit.

Ha egyik feltétel sem teljesül, a relációs adatmodellt kell használnia. Ha például az adatok XML formátumúak, de az alkalmazás csak az adatbázist használja az adatok tárolására és lekérésére, csak egy [n]varchar(max) oszlop szükséges. Az adatok XML-oszlopban való tárolása további előnyökkel jár. Ez magában foglalja, hogy a motor megállapítja, hogy az adatok megfelelően vannak formázva vagy érvényesek, valamint támogatja a részletes lekérdezéseket és frissítéseket az XML-adatokban.

Az XML-adatok SQL Serverben való tárolásának okai

Az alábbiakban bemutatjuk, hogy miért érdemes natív XML-funkciókat használni az SQL Serverben ahelyett, hogy az XML-adatokat a fájlrendszerben kezelned kell:

  • Az XML-adatokat hatékony és átható módon szeretné megosztani, lekérdezni és módosítani. Az alkalmazás számára fontos a részletes adathozzáférés. Előfordulhat például, hogy ki szeretne nyerni néhány szakaszt egy XML-dokumentumban, vagy be szeretne szúrni egy új szakaszt a teljes dokumentum cseréje nélkül.

  • Rendelkezik relációs adatokkal és XML-adatokkal, és az alkalmazáson belüli relációs és XML-adatok közötti együttműködést szeretné elérni.

  • Tartományközi alkalmazások lekérdezéséhez és adatmódosításához nyelvi támogatásra van szüksége.

  • Azt szeretné, hogy a kiszolgáló garantálja, hogy az adatok megfelelően formázottak, és opcionálisan xml-sémák szerint is érvényesítse az adatokat.

  • Az XML-adatok indexelését szeretné a hatékony lekérdezésfeldolgozás és a jó skálázhatóság érdekében, valamint az első osztályú lekérdezésoptimalizáló használatát.

  • SOAP-, ADO.NET- és OLE DB-hozzáférést szeretne az XML-adatokhoz.

  • Az ADATBÁZIS-kiszolgáló felügyeleti funkcióit szeretné használni az XML-adatok kezeléséhez. Ez lehet például a biztonsági mentés, a helyreállítás és a replikáció.

Ha egyik feltétel sem teljesül, jobb lehet, ha az adatokat nem XML-alapú, nagy objektumtípusként tárolja, például [n]varchar(max) vagy varbinary(max).

XML-tárolási lehetőségek

Az SQL Server XML-tárolóbeállításai a következők:

  • Natív tárolás XML-adattípusként

    Az adatok tárolása belső reprezentációban történik, amely megőrzi az adatok XML-tartalmát. Ez a belső ábrázolás információkat tartalmaz az elszigetelési hierarchiáról, a dokumentumrendről, valamint az elem- és attribútumértékekről. Pontosabban az XML-adatok InfoSet-tartalma megmarad. További információ az InfoSetről: http://www.w3.org/TR/xml-infoset. Az InfoSet-tartalom nem lehet a szöveges XML azonos példánya, mert a következő információk nem maradnak meg: jelentéktelen szóközök, attribútumok sorrendje, névtér-előtagok és XML-deklaráció.

    A beírt XML-adattípus esetében az XML-sémákhoz kötött XML-adattípus, a séma utáni érvényesítési InfoSet (PSVI) típusinformációkat ad hozzá az InfoSethez, és a belső ábrázolásban van kódolva. Ez jelentősen javítja az elemzési sebességet. További információkért lásd a W3C XML-séma specifikációit a következő helyeken: http://www.w3.org/TR/xmlschema-1 és http://www.w3.org/TR/xmlschema-2.

  • Megfeleltetés AZ XML és a relációs tároló között

    Jegyzetekkel ellátott séma (AXSD) használatával az XML egy vagy több tábla oszlopaira lesz bontva. Ez megőrzi az adatok megbízhatóságát a relációs szinten. Ennek eredményeképpen a hierarchikus struktúra megmarad, bár az elemek közötti sorrend figyelmen kívül marad. A séma nem lehet rekurzív.

  • Nagyméretű objektumtároló, [n]varchar(max) és varbinary(max)

    A rendszer az adatok azonos másolatát tárolja. Ez hasznos különleges célú alkalmazásokhoz, például jogi dokumentumokhoz. A legtöbb alkalmazás nem igényel pontos másolatot, és elégedett az XML-tartalommal (InfoSet fidelity).

Általában előfordulhat, hogy ezeknek a megközelítéseknek a kombinációját kell használnia. Előfordulhat például, hogy az XML-adatokat egy XML-adattípus oszlopban szeretné tárolni, és a tulajdonságokat relációs oszlopokba szeretné előléptetni. Vagy a leképezési technológiával nem rekurzív részeket tárolhat nem XML-oszlopokban, és csak a rekurzív részeket XML-adattípusú oszlopokban.

Xml-technológia kiválasztása

Az XML-technológia, a natív XML és az XML nézet kiválasztása általában a következő tényezőktől függ:

  • Tárolási lehetőségek

    Előfordulhat, hogy az XML-adatok megfelelőbbek a nagyméretű objektumtároláshoz (például egy termék kézikönyvéhez), vagy jobban kezelhetők a relációs oszlopokban való tároláshoz (például egy XML-vé konvertált sorelemhez). Minden tárolási beállítás más-más mértékben őrzi meg a dokumentumok hűségét.

  • Lekérdezési képességek

    A lekérdezések természete és az XML-adatok lekérdezésének mértéke alapján az egyik tárolási lehetőség a másiknál megfelelőbb lehet. Az XML-adatok részletes lekérdezése, például az XML-csomópontok predikátum-kiértékelése a két tárolási lehetőségben különböző mértékben támogatott.

  • XML-adatok indexelése

    Érdemes lehet indexelni az XML-adatokat az XML-lekérdezés teljesítményének felgyorsítása érdekében. Az indexelési beállítások a tárolási beállításoktól függően változnak; a számítási feladat optimalizálásához meg kell hoznia a megfelelő döntést.

  • Adatmódosítási képességek

    Egyes számítási feladatok az XML-adatok részletes módosításával járnak. Ez magában foglalhatja például egy új szakasz hozzáadását egy dokumentumon belül, míg más számítási feladatok, például a webes tartalmak nem. Az adatmódosítás nyelvének támogatása fontos lehet az alkalmazás számára.

  • Sématámogatás

    Az XML-adatokat egy olyan séma írhatja le, amely lehet, hogy nem XML-sémadokumentum. A sémaalapú XML támogatása az XML-technológiától függ.

A különböző választási lehetőségek eltérő teljesítményjellemzőkkel is rendelkeznek.

Natív XML-tároló

Az XML-adatokat egy XML-adattípus oszlopban tárolhatja a kiszolgálón. Ez megfelelő választás, ha az alábbiak érvényesek:

  • Egyszerű módot szeretne arra, hogy az XML-adatokat a kiszolgálón tárolja, ugyanakkor megőrizze a dokumentumsorrendet és a dokumentumstruktúrát.

  • Előfordulhat, hogy nem rendelkezik sémával az XML-adatokhoz.

  • Le szeretné kérdezni és módosítani az XML-adatokat.

  • A lekérdezések gyorsabb feldolgozása érdekében indexelni szeretné az XML-adatokat.

  • Az alkalmazásnak rendszerkatalógus-nézetekre van szüksége az XML-adatok és AZ XML-sémák kezeléséhez.

A natív XML-tárolás akkor hasznos, ha olyan XML-dokumentumokkal rendelkezik, amelyek több struktúrával rendelkeznek, vagy olyan XML-dokumentumokkal rendelkezik, amelyek különböző vagy összetett sémáknak felelnek meg, amelyek túl nehezen képezhetők le relációs struktúrákra.

Példa: XML-adatok modellezése xml-adattípussal

Fontolja meg egy xml formátumú termék kézikönyvét, amely minden témakörhöz külön fejezetből áll, és amely az egyes fejezetekben több szakaszból áll. A szakaszok alszakaszokat tartalmazhatnak. Ennek eredményeként <section> rekurzív elem. A termék kézikönyvei nagy mennyiségű vegyes tartalmat, diagramot és műszaki anyagot tartalmaznak; az adatok félig strukturáltak. Előfordulhat, hogy a felhasználók környezetfüggő keresést szeretnének végezni az érdekes témákban, például az "indexelés" fejezet "fürtözött index" szakaszának keresését, valamint a műszaki mennyiségeket kérdezik le.

Az XML-dokumentumok megfelelő tárolási modellje egy XML-adattípus-oszlop . Ez megőrzi az XML-adatok InfoSet-tartalmát. Az XML-oszlop indexelése előnyös a lekérdezési teljesítmény szempontjából.

Példa: Az XML-adatok pontos másolatainak megőrzése

Illusztrációként tegyük fel, hogy a kormányzati szabályozás megköveteli az XML-dokumentumok pontos szöveges másolatának megőrzését. Ilyenek lehetnek például az aláírt dokumentumok, a jogi dokumentumok vagy a részvénytranzakciós rendelések. Előfordulhat, hogy a dokumentumokat egy [n]varchar(max) oszlopban szeretné tárolni.

Lekérdezéshez konvertálja az adatokat xml-adattípussá futáskor, és hajtsa végre az XQueryt rajta. A futásidejű átalakítás költséges lehet, különösen akkor, ha a dokumentum nagy. Ha gyakran kérdez le, redundánsan tárolhatja a dokumentumokat egy XML-adattípus oszlopban, és indexelheti, miközben pontos dokumentummásolatokat ad vissza az [n]varchar(max) oszlopból.

Az XML-oszlop lehet számított oszlop a [n]varchar(max) oszlop alapján. Azonban nem hozhat létre XML-indexet számított, XML-oszlopon, és nem építhető XML-index [n]varchar(max) vagy varbinary(max) oszlopokra.

XML-nézet technológiája

Az XML-sémák és az adatbázis táblái közötti megfeleltetés meghatározásával xml-nézetet hozhat létre az állandó adatokról. Az XML-tömeges terhelés az alapul szolgáló táblák XML-nézet használatával való feltöltésére használható. Az XML-nézetet az XPath 1.0-s verziójával kérdezheti le; a lekérdezést a rendszer lefordítja a táblákon lévő SQL-lekérdezésekre. Hasonlóképpen a frissítéseket is propagálja a rendszer ezekre a táblákra.

Ez a technológia a következő helyzetekben hasznos:

  • Xml-központú programozási modellt szeretne használni, amely XML-nézeteket használ a meglévő relációs adatokon.

  • Rendelkezik egy sémával (XSD, XDR) az XML-adatokhoz, amelyeket egy külső partner adott meg.

  • A sorrend nem fontos az adatokban, vagy a lekérdezéstáblák adatai nem rekurzívak, vagy előre ismert a maximális rekurziós mélység.

  • Az adatokat az XPath 1.0-s verziójával szeretné lekérdezni és módosítani az XML-nézetben.

  • Az XML-adatokat tömegesen szeretné betölteni, és az XML-nézet használatával bontani azokat a mögöttes táblákba.

Ilyenek például az adatcsere és webszolgáltatások XML-ként közzétett relációs adatai, valamint a rögzített sémával rendelkező XML-adatok. További információkért.

Példa: Adatok modellezése jegyzetekkel ellátott XML-sémával (AXSD)

Illusztrációként tegyük fel, hogy rendelkezik olyan meglévő relációs adatokkal, mint például az ügyfelek, a rendelések és a sorelemek, amelyeket XML-ként szeretne kezelni. Xml-nézet definiálása az AXSD használatával a relációs adatokon keresztül. Az XML-nézet lehetővé teszi az XML-adatok tömeges betöltését a táblákba, és az XML-nézet használatával lekérdezheti és frissítheti a relációs adatokat. Ez a modell akkor hasznos, ha xml-korrektúrát tartalmazó adatokat kell cserélnie más alkalmazásokkal, miközben az SQL-alkalmazások zavartalanul működnek.

Hibrid modell

Az adatmodellezéshez gyakran a relációs és xml adattípusú oszlopok kombinációja megfelelő. Az XML-adatokból származó értékek egy része relációs oszlopokban, a többiben vagy az XML-oszlopban tárolt teljes XML-értékben tárolható. Ez jobb teljesítményt eredményezhet, ha jobban szabályozhatja a relációs oszlopokon létrehozott indexeket és a zárolási jellemzőket.

A relációs oszlopokban tárolandó értékek a számítási feladattól függenek. Például, ha az elérési út kifejezése alapján lekéri az összes XML-értéket, és az /Customer/@CustId attribútum értékét egy relációs oszlopba emeli, majd indexeli, az gyorsabb lekérdezési teljesítményt eredményezhet. Ha viszont az XML-adatok nagy mértékben és nem relációs oszlopokra bontva vannak, az újraépítés költsége jelentős lehet.

A nagymértékben strukturált XML-adatok esetében például a tábla tartalma XML-fájllá lett konvertálva; az összes értéket megfeleltetheti relációs oszlopokra, és használhat XML-nézettechnológiát is.

AZ XML-adatok részletessége

Az XML-oszlopban tárolt XML-adatok részletessége fontos a zároláshoz, és kisebb mértékben a frissítések esetében is fontos. Az SQL Server ugyanazt a zárolási mechanizmust használja az XML- és a nem XML-adatokhoz is. Ezért a sorszintű zárolás miatt a sor összes XML-példánya zárolva van. Ha a részletesség nagy, a nagy XML-példányok frissítésekhez való zárolása a többfelhasználós forgatókönyvekben az átviteli sebesség csökkenését okozza. Másrészt a súlyos felbontás elveszíti az objektumok beágyazódását, és növeli az újraépítés költségeit.

Az adatmodellezési követelmények, valamint a zárolási és frissítési jellemzők közötti egyensúly fontos a jó tervezéshez. Az SQL Serverben azonban a tényleges tárolt XML-példányok mérete nem olyan kritikus.

Az XML-példányok frissítései például olyan részleges bináris nagyméretű objektumok (BLOB) és részleges indexfrissítések új támogatásával hajthatók végre, amelyekben a meglévő tárolt XML-példányt összehasonlítják a frissített verzióval. A részleges bináris nagy objektum (BLOB) frissítése különbségi összehasonlítást végez a két XML-példány között, és csak a különbségeket frissíti. A részleges indexfrissítések csak azokat a sorokat módosítják, amelyeket módosítani kell az XML-indexben.

Az xml-adattípus korlátozásai

Vegye figyelembe az xml-adattípusra vonatkozó alábbi általános korlátozásokat:

  • Az XML-adattípus-példányok tárolt megjelenítése nem haladhatja meg a 2 GB-ot.

  • Nem használható sql_variant példány altípusaként.

  • Nem támogatja az öntést vagy a szöveggé vagy az ntextre való konvertálást. Helyette használjon varchar(max) vagy nvarchar(max) elemet.

  • Nem hasonlítható össze és nem rendezhető. Ez azt jelenti, hogy az XML-adattípus nem használható a GROUP BY utasításban.

  • Nem használható paraméterként az ISNULL, a COALESCE és a DATALENGTH kivételével bármely skaláris, beépített függvényhez.

  • Nem használható kulcsoszlopként egy indexben. Azonban szerepelhet adatokként egy fürtözött indexben, vagy kifejezetten hozzáadható egy nemclustered indexhez az INCLUDE kulcsszó használatával, amikor létrejön a nemclustered index.

  • Az XML-elemek legfeljebb 128 szintbe ágyazhatók.

Lásd még

  • Last updated on