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

Quando dovrei usare il tipo di dati XML in Microsoft SQL Server?

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

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

Il miglior caso aziendale che posso vedere potrebbe essere la registrazione di messaggi di dati basati su XML che hai ricevuto dove potresti voler sbirciare nella loro struttura e dati, ma vuoi mantenere l'integrità del messaggio originale per motivi commerciali 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 semplicemente ridurre il costo dell'esame dei dati abbastanza da giustificare l'utilizzo.

Probabilmente ci sono dozzine di altri motivi per cui vorresti usarlo, ma francamente penso che dovresti considerare altri percorsi per la felicità prima di scatenarti con XML in SQL Server a meno che tu non abbia ragioni aziendali molto specifiche per farlo. Utilizzare un campo varchar (max) o di testo se ha più senso.

Solo la mia opinione, ovviamente :)

Ho riscontrato solo alcuni scenari in cui avrei attivamente perseguito l'uso del tipo di dati XML in SQL Server. Questo è fuori dalla mia testa, in ordine dal meno interessante:

• Memorizzazione / archiviazione delle risposte XML generate da altre applicazioni
  • Ad esempio, utilizziamo Application Integration Framework (AIF) per comunicare tra un'applicazione Silverlight personalizzata e Dynamics AX. Archiviamo sia i messaggi in entrata che quelli in uscita nel database per facilitare la risoluzione dei problemi di comunicazione tra tali applicazioni
  • Poiché il tipo di campo è XML anziché un tipo di stringa generico (ad es. VARCHAR), siamo in grado di utilizzare XQuery per eseguire una query specifica per i messaggi che soddisfano alcuni criteri specifici. Questo sarebbe molto più difficile con la semplice stringa LIKE matching
• Memorizzazione nella cache / persistenza di un messaggio di risposta composto
  • Aggiorna il campo XML con un trigger o un codice dell'applicazione, che simulerebbe una colonna calcolata
  • Invece di rigenerare costantemente una risposta XML a un'applicazione di chiamata in base, si verificherebbe un sovraccarico solo quando la riga è inversa, piuttosto che su ogni chiamata
  • Funziona meglio quando i SELECT sono molto più frequenti degli UPDATE / INSERT, il 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 chiave / valore
  • Un aspetto negativo di questo è che i dati non sono completamente normalizzati, rendendo meno ovvia l'interrogazione
  • Tuttavia, come accennato in precedenza, è possibile utilizzare XQuery su quel campo XML per selezionare le righe che corrispondono ai criteri di identificazione, in tal modo parzialmente nuetralizzando l'impatto del non essere completamente normalizzato.

Detto questo, il 99% delle volte, non ho assolutamente bisogno di un campo XML durante la progettazione di uno schema.

Le poche volte in cui ho visto il tipo di dati XML nel server SQL è stato sostanzialmente utilizzato come campo interrogato come qualsiasi altro nel database, il che può avere delle pessime implicazioni sulle prestazioni se si dispone di una grande quantità di dati . C'è un motivo per cui si chiama server SQL e non server XML. :-) Le query che vanno contro l'XML semplicemente non sono così veloci come una normale query di selezione.

Potevo vederlo essere utilizzato per archiviare XML che non è stato interrogato così tanto, ad esempio archiviando l'intero documento XML in un tipo di dati XML, ma avendo i campi ricercabili (chiavi) memorizzati separatamente con il documento XML. In questo modo puoi interrogare le tue informazioni più velocemente ed estrarre 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 cercato di utilizzare il tipo di dati XML come campo fortemente interrogato e i dati sono cresciuti al punto in cui la query è diventata troppo lenta.

Ho utilizzato i campi di tipo XML principalmente per scopi di registrazione relativi ai servizi Web ASMX o ai servizi WCF. È possibile salvare la richiesta o i messaggi di risposta.

Il più delle volte, si salva l'XML nel DB a scopo di riferimento, non per la normale attività aziendale (non per interrogarlo ogni 5 secondi dal codice). Se ti ritrovi a farlo, determina i campi che di solito richiedi o usi la maggior parte delle volte 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. Successivamente, durante il loro recupero, non è necessario interrogare il documento XML, ma è possibile utilizzare solo le colonne create a tale scopo.

Questi sono gli scenari che vengono immediatamente in mente per capriccio quando si considerano le condizioni che dovrebbero esistere per consentire i campi Xml in SQL Server:

• dati binari codificati per l'interscambio in cui si desidera il controllo acido della risorsa
• frammenti di documenti che verranno ricostituiti integralmente utilizzando informazioni dinamiche
• l'utente ha inviato documenti o frammenti che si desidera isolare e almeno su base temporanea tenere lontano direttamente il file system.

Uso ampiamente XML nelle app client-server per salvare dati strutturati in una singola chiamata al database. Ad esempio, prendi una fattura con righe di dettaglio. È semplice fare in modo che il client serializzi l'oggetto business in XML e passi a un proc memorizzato in una singola chiamata. Il proc decide se è necessario inserire o aggiornare; può ottenere l'ID della fattura principale (una colonna di identità) da assegnare ai record di dettaglio, il tutto all'interno di una transazione sul lato server e senza che il cliente debba effettuare diversi round trip. Non ho bisogno di circa 20 parametri per specificare il record dell'intestazione e non devo effettuare una chiamata per ogni riga della fattura. Inoltre, è spesso possibile apportare modifiche allo schema o introdurre la registrazione / il controllo, senza dover toccare il client.