In quale tipo di dati archiviare i dati XML: VARCHAR (MAX) o XML


9

Sto definendo uno schema per un nuovo set di risorse usando SQL Server 2008 ... In questo caso, ogni record ( ad es. Riga ) dovrà archiviare frammenti XML. Di volta in volta; sebbene non frequentemente; Avrò bisogno di interrogare l'XML per trovare i valori degli elementi e degli attributi. Se lasciato alle mie stesse idee, tenderei ad usare il tipo di dati xml anche se sono stato indotto a credere che questo sia un problema. Questo mi porta alle mie domande.

Dato questo scenario, quali fattori dovrei prendere in considerazione quando si cerca di decidere tra la memorizzazione di XML in un xml colonna rispetto a un varchar (MAX) di colonna

Se aiuta ... ecco alcuni dettagli aggiuntivi:

  • Non è stata presa alcuna decisione riguardo all'uso degli schemi per questi frammenti ( ad es. XSD )
  • Le dimensioni dei frammenti varieranno da piccole a molto grandi
  • Tutto l'XML sarà ben formato
  • Nel corso di una giornata, verranno raccolti fino a ~ 10.000 frammenti con supporto di query online necessari per ~ 3 mesi
  • Le query contro l'XML verranno eseguite durante il giorno, ma dovrebbero rimanere chiare con alcune query simultanee di questo tipo

1
Il tipo xml non garantisce di preservare la forma esatta dell'xml originale, se è necessario che il documento rimanga invariato, allora nvarchar (max) è l'unica opzione.
MartinC,

@MartinC Se il frammento è già ben formato, che tipo di cambiamento potrebbe verificarsi? Ti credo, non l'ho mai sentito prima ... Puoi indicarmi qualche dettaglio in più?
JoeGeeky,

Ad esempio, i tag vuoti <foo></foo>diventeranno<foo />
gbn

@gdn Ahhh, ok ... questo non cambia il significato, quindi per me va bene.
JoeGeeky,

Risposte:


5

Se le query sull'XML verranno eseguite dalle funzionalità XML del server sql, utilizzare il tipo XML per archiviare un XML per evitare il casting

E

tieni presente che il tipo di XML può essere archiviato un po 'più lentamente a causa della convalida XML, ma il tipo di XML sottostante è una variante ordinaria (max)


1
I dati sottostanti non lo sono VARBINARY(MAX). È un formato ottimizzato, il che significa che anche se non hai intenzione di interrogarlo, dovresti comunque usare il XMLtipo di dati.
Solomon Rutzky,

6

quali fattori dovrei considerare quando provo a decidere tra l'archiviazione di XML in una xmlcolonna rispetto a una varchar(MAX)colonna

I fattori sono:

  1. Il XMLtipo è interrogabile / analizzabile tramite le espressioni XQuery, inclusa la possibilità di utilizzare l' istruzione e l'iterazione FLWOR
  2. I dati in XMLvariabili e colonne possono essere modificati in linea utilizzando le espressioni XQuery tramite XML DML .
  3. XMLi dati sono memorizzati come UTF-16 LE (Little Endian), quindi VARCHAR(MAX)sarebbe una scelta sbagliata in quanto potrebbe causare la perdita di dati. Quindi, la vera decisione dovrebbe essere tra XMLe NVARCHAR(MAX), dato che NCHAR/ NVARCHARè anche UTF-16 LE.
  4. XMLi dati possono essere validati su un XSD / XML SCHEMA COLLECTION. Non viene eseguita alcuna convalida (al di fuori di garantire la buona formalità) se non viene specificata alcuna raccolta di schemi XML, ma questa opzione non è disponibile durante l'utilizzo NVARCHAR(MAX).
  5. Uno dei principali vantaggi del tipo XML è che è archiviato in un formato altamente ottimizzato (non VARBINARY(MAX)come indicato nella risposta di @ Oleg) che non memorizza l'esatta rappresentazione di stringa che vedi, ma ha invece un dizionario di nomi di elementi e attributi e fa riferimento a loro dal loro ID. Rimuove anche gli spazi bianchi. Prova quanto segue:

    DECLARE @Test1 XML = N'<Test><TagName>1</TagName><TagName>2</TagName></Test>';
    
    DECLARE @String1 NVARCHAR(MAX) = CONVERT(NVARCHAR(MAX), @Test1);
    
    SELECT DATALENGTH(@Test1) AS [XmlBytes],
           LEN(@String1) AS [StringCharacters],
           DATALENGTH(@String1) AS [StringBytes];
    
    SET @Test1 = N'<Test><TagName>1</TagName><TagName>2</TagName><TagName>3</TagName>
    <TagName>4</TagName><TagName>5</TagName><TagName>6</TagName></Test>';
    
    SET @String1 = CONVERT(NVARCHAR(MAX), @Test1);
    
    SELECT DATALENGTH(@Test1) AS [XmlBytes],
           LEN(@String1) AS [StringCharacters],
           DATALENGTH(@String1) AS [StringBytes];

    Ritorna:

    XmlBytes   StringCharacters   StringBytes
    56         53                 106
    
    XmlBytes   StringCharacters   StringBytes
    84         133                266

    Come puoi vedere nell'esempio sopra, l'aggiunta di quattro elementi (# 3, 4, 5 e 6) ha aggiunto 80 caratteri (quindi 80 byte se si utilizza VARCHAR) e 160 byte alla NVARCHARvariabile. Tuttavia, ha aggiunto solo 28 byte alla variabile XML, che è inferiore a quella aggiunta VARCHAR(nel caso in cui qualcuno avrebbe discusso a favore di VARCHARover XMLperché XMLè UTF-16 che è [principalmente] doppio byte). Questa ottimizzazione può risparmiare tonnellate di spazio ed è una ragione sufficiente da sola per utilizzare il XMLtipo di dati.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.