Quando devo usare il tipo di dati XML in SQL Server?

Personalmente, non ho mai usato il tipo di campo XML in SQL Server prima, e ho fatto un sacco di programmazione del database da quando hanno aggiunto questa funzione. Mi è sempre sembrato un sovraccarico programmatico e prestazionale rispetto all'utilizzo del contenuto XML in un database in modo nativo. Onestamente ho pensato che fosse un trucco, perché tutti erano sul treno XML a un certo punto nei primi anni 2000. "Oh XML è caldo, quindi aggiungiamolo a SQL Server in modo da non sembrare passe".

Il miglior caso di business che riesco a vedere potrebbe riguardare la registrazione di messaggi di dati basati su XML che hai ricevuto dove potresti dare un'occhiata alla loro struttura e ai loro dati, ma volere mantenere l'integrità del messaggio originale per motivi aziendali o legali. Il sovraccarico potrebbe essere troppo grande per tradurre l'XML in una struttura di tabella, ma l'utilizzo delle funzionalità XML in SQL Server potrebbe ridurre il costo dell'esame dei dati sufficiente a giustificarne l'utilizzo.

Ci sono probabilmente dozzine di altri motivi per cui vorresti usarlo, ma sinceramente penso che dovresti prendere in considerazione altri percorsi di felicità prima di andare hog-wild con XML in SQL Server a meno che tu non abbia ragioni commerciali molto specifiche per farlo. Utilizza un campo varchar (massimo) o di testo se ha più senso.

Solo la mia opinione, ovviamente:)

Ho incontrato solo alcuni scenari in cui vorrei perseguire attivamente l'uso del tipo di dati XML in SQL Server. Questo è fuori di testa, in ordine dal meno al più interessante:

• Archiviazione / archiviazione di risposte XML generate da altre applicazioni
  • Ad esempio, utilizziamo Application Integration Framework (AIF) per la comunicazione tra un'applicazione Silverlight personalizzata e Dynamics AX. Archiviamo sia i messaggi in entrata che quelli in uscita nel database per aiutare nella risoluzione dei problemi di comunicazione tra quelle applicazioni
  • Poiché il tipo di campo è XML piuttosto che un tipo di stringa generico (ad esempio VARCHAR), possiamo usare XQuery per interrogare specificamente i messaggi che corrispondono ad alcuni criteri specifici. Ciò sarebbe molto più difficile con la semplice corrispondenza della stringa LIKE
• Memorizzazione nella cache / mantenimento di un messaggio di risposta composto
  • Aggiorna il campo XML con un codice di attivazione o applicazione, che simulerebbe una colonna calcolata
  • Invece di rigenerare costantemente una risposta XML a un'applicazione chiamante in base, si verificherebbe un sovraccarico solo quando la riga viene incrementata, anziché su ogni chiamata
  • Funziona meglio quando gli SELECT sono molto più frequenti di UPDATE / INSERT, che tende ad essere vero per la maggior parte delle applicazioni
• Memorizzazione di più valori in un singolo campo
  • Una delle pratiche che ho visto è l'uso del tipo di dati XML per memorizzare una raccolta di valori in un singolo campo
  • Un vantaggio è che non è necessario progettare un set aggiuntivo di tabelle per un semplice archivio di chiavi / valori
  • Uno svantaggio di questo è che i dati non sono completamente normalizzati, rendendo l'interrogazione meno ovvia
  • Tuttavia, come menzionato sopra, è possibile utilizzare XQuery su quel campo XML per selezionare le righe che corrispondono ai criteri di identificazione, in tal modo parzialmente neutralizzando l'impatto di non essere completamente normalizzati.

Tutto ciò che ho detto, il 99% delle volte, non ho assolutamente bisogno di un campo XML durante la progettazione di uno schema.

Le poche volte che ho visto il tipo di dati XML nel server SQL è stato fondamentalmente usato come un campo che è stato interrogato come qualsiasi altro nel database, il che può avere conseguenze molto negative sulle prestazioni se si dispone di un grande quantità di dati. C'è un motivo per cui si chiama server SQL e non server XML. :-) Le query che vanno contro l'XML non sono così veloci come fare una query di selezione regolare.

Potrei vederlo essere usato per memorizzare XML che non viene interrogato più di tanto, anche se, ad esempio, si memorizza il documento XML completo in un tipo di dati XML, ma con i campi ricercabili (chiavi) memorizzati separatamente con il documento XML. In questo modo puoi interrogare più rapidamente le tue informazioni e tirare su il documento XML quando arrivi al punto in cui vuoi vedere il documento completo. In realtà ho dovuto tornare indietro e farlo con un numero di app in cui le persone hanno provato a utilizzare il tipo di dati XML come un campo pesantemente interrogato ei dati sono cresciuti fino al punto in cui la query è diventata troppo lenta.

Ho usato campi tipo XML principalmente per scopi di registrazione relativi ai servizi web ASMX o ai servizi WCF. Puoi salvare la richiesta o i messaggi di risposta.

La maggior parte delle volte, si salva l'XML nel DB a scopo di riferimento, non per la normale attività commerciale (non per interrogarlo ogni 5 secondi dal codice). Se ti accorgi di farlo, determina i campi che solitamente richiedi o utilizzi la maggior parte del tempo e crea colonne separate per loro. In questo modo, quando si salva l'XML nel DB, è possibile estrarre questi campi e salvarli nelle colonne corrispondenti. In seguito, mentre li recuperi, non hai bisogno di interrogare il documento XML, puoi semplicemente usare le colonne che hai creato per questo scopo.

Ho fatto una cosa simile dove serializzo i dati degli oggetti in XML per l'archiviazione. Ciò elimina l'onere di disporre di tabelle, colonne e relazioni per conservare i dati per oggetti complessi. Il processo può essere aiutato utilizzando uno schema a cui il risultato XML è conforme e le tabelle del database possono essere utilizzate per le meta informazioni sugli oggetti in questione. Nel mio caso, espandere lo schema del database per accogliere il layout dell'oggetto sarebbe un compito importante!

Questi sono gli scenari che vengono in mente immediatamente quando capisci quali condizioni dovrebbero esistere per consentire i campi Xml in Sql Server:

• dati binari codificati per l'interscambio dove vuoi il controllo acido di la risorsa
• frammenti di documenti che verranno ricostituiti per intero utilizzando la dinamica Informazioni
• l'utente ha inviato documenti o frammenti che si desidera isolare e almeno su una base provvisoria mantenere dal file system direttamente.