Determinare se memorizzare i dati XML come XML o in tabelle normalizzate

Question

(Questo post è sollecitare esperienze personali sulla memorizzazione XML;. Si prega di condividere ciò che si sa :-))

Sto lavorando su un'applicazione di servizio che comunica con un servizio esterno che utilizza XML. Sto pianificando di utilizzare SQL Server 2008 per archiviare l'XML ricevuto e inviato al servizio esterno. Sto esplorando le mie opzioni per l'archiviazione dell'XML nel database. Le tre opzioni che ho individuate sono:

1. Conservare l'XML in una colonna di tipo di dati XML
2. creare le tabelle per memorizzare le varie relazioni padre e figlio rappresentate nel XML.
3. Un ibrido dei due precedenti approcci in cui l'XML originale è memorizzato in una colonna di tipo di dati XML ma diversi campi dell'XML sono suddivisi nelle proprie colonne per semplificare le query e l'indicizzazione.

Sto cercando qualsiasi consiglio, in base alla vostra esperienza personale, con l'archiviazione e il recupero di dati XML in SQL Server.

Alcuni dati aggiuntivi: ho utilizzato un equivalente 'xsd.exe' chiamato XsdObjectgenerator per creare classi .net basate sugli schemi XML. Quando il servizio riceve il file XML, viene deserializzato in un'istanza di classe .net. Questa istanza viene utilizzata per eseguire le operazioni del servizio. Il mio piano originale era quindi utilizzare l'opzione n. 1 sopra per memorizzare l'XML. Se dovessi aggiornare o riportare i dati, avrei semplicemente deserializzato il record db in una delle mie classi .net.

Anche se questo approccio funziona e semplifica il lavoro con l'xml, temo che con l'aumento del volume di dati, le prestazioni di query sui record dei tipi di dati XML diminuiscano. Questo è il motivo per cui ho esplorato le opzioni 2. & 3. sopra.

Oltre all'archiviazione dell'XML, l'XML verrà interrogato per l'utilizzo in entrambi i report e in un'applicazione Web separata. I record db verranno interrogati, ordinati, filtrati, raggruppati, sommati e eventualmente aggiornati dagli utenti finali.

Answer 1

Suppongo che dipenda da cosa vuoi fare con il tuo XML nel tuo database.

Se per lo più lo si memorizza e lo si recupera in un secondo momento nel suo insieme e lo si invia di nuovo, allora sicuramente utilizzerò il tipo di dati XML, senza alcun motivo per distruggerlo in frammenti.

Se è comunque necessario lavorare principalmente con i contenuti del file XML e possibilmente manipolare e modificare tale contenuto, potrebbe essere consigliabile creare tabelle con colonne per abbinare il contenuto XML e distruggerlo quando lo si archivia , usalo, e quando è necessario, rimontalo dai pezzi relazionali usando qualcosa come SELECT (columns) FROM dbo.Table FOR XML.....

C'è un sovraccarico nella distruzione e nel rimontaggio - quindi è necessario chiedersi se vale la pena farlo. Ma c'è anche un sovraccarico se hai bisogno di manipolare troppo la colonna XML.

Se è necessario solo l'accesso in sola lettura ad alcuni attributi nel proprio XML, ho imparato ad apprezzare la possibilità di racchiuderlo in una UDF e visualizzarla come una colonna calcolata nella tabella. In questo modo, puoi facilmente selezionare qualcosa dalla tua tabella, in base ai valori che sono memorizzati da qualche parte all'interno del tuo XML - molto utile! Ma non esagerare con questo approccio - funziona bene per 2, 3 attributi - ma se hai bisogno di accedere al tuo XML più e più volte (e in gran parte o tutti), allora potresti essere meglio sminuzzarlo in pezzi relazionali per cominciare .

Answer 2

pur continuando ad esplorare soluzioni, un collega ha trasmesso i seguenti link applicabili:

• SQL Server Performance with Key/Pair Table vs XML Field and XPath
• XML Support in Microsoft SQL Server 2005

Alcune conclusioni preliminari da questi articoli e altre ricerche:

• Mentre si lavora con dat xml atype in SQL Server è flessibile, l'interrogazione di grandi volumi di dati sarà lenta in quanto si sta essenzialmente interrogando un tipo di dati blob.
• Mentre è possibile creare indici su colonne di tipi di dati xml in Sql Server, l'indice si trova sull'intera colonna e non su un particolare elemento o attributo, pertanto gli indici non sono efficaci come un indice su una colonna db non xml.
• Memorizzazione XML in forma grezza in un campo di tipo di dati XML pur mantenendo una versione analizzata dei dati in sia tabelle relazionali o tavola piana denormalizzato (s) per interrogazione e reporting sta cominciando emergere come soluzione più flessibile . L'xml può essere "sminuzzato" nelle tabelle di interrogazione o al runtime o dopo il fatto da un servizio separato o thread .

Sarò sdoganando ogni soluzione con i dati di test e eseguendo alcuni benchmarking. Pubblicherò i risultati qui una volta disponibili.

Answer 3

Alcuni lavori indietro (SQL 2000), stavamo memorizzando XML come dati TEXT, e il nostro database è diventato notevolmente gonfio - non tanto con i dati come con i tag utilizzati per identificarlo. Ho fatto alcuni test e pkzip (ho detto che erano diversi lavori fa) ha ridotto tutti i dati al 3% delle dimensioni originali.

Consiglio n. 1: identificare per quanto tempo è necessario archiviare i dati e se/quando possibile archiviare i vecchi dati.

Consiglio n. 2: se si utilizza SQL 2008, esaminare le opzioni di compressione dei dati per le colonne XML.

(Potrebbe non essere rilevante se i tuoi XMLs sono brevi, ma la nostra erano tutti nelle kbs e 10kbs.)