Progettazione della tabella per archiviare dati XML in SQL Server 2008 R2

Sto pianificando di utilizzare SQL Server per archiviare BLOB XML per la mia applicazione. Sono alle prese con una decisione di progettazione e alla ricerca di linee guida o consigli da qualcuno esperto in questo argomento.Progettazione della tabella per archiviare dati XML in SQL Server 2008 R2

I dati che devono essere memorizzati in formato XML ha circa 100 punti di dati semplici. Possono essere facilmente catalogati in gruppi di 20 punti dati ciascuno. Nelle versioni future dell'applicazione, intendiamo aumentare l'ambito dei dati aggiungendo nuovi punti dati, alcuni dei quali saranno gerarchici (elenchi, dizionari, ecc.).

Non stiamo anticipando la necessità di eseguire query sui dati XML. Al massimo saranno domande molto semplici e, se necessario, potremo promuovere qualsiasi punto dati su una colonna relazionale.

Non sono sicuro se devo solo creare un gigante BLOB XML per contenere tutti questi dati, o se dovrei scomposizione in più colonne XML. Esistono best practice o linee guida per gestire il tipo di dati XML in SQL Server 2008 R2 che può aiutarmi a prendere la decisione migliore? Ha importanza?

EDIT: Sono già impostato sull'utilizzo di XML come un tipo di dati, sto cercando di decidere se utilizzare un BLOB di grandi dimensioni o suddividerlo in più colonne XML.

fonte

2013-08-06 Dan Ling

Hai visto questo? http://msdn.microsoft.com/en-us/library/hh403385.aspx –

Mikael, ho già letto tutto questo. Tuttavia non sono ancora sicuro se abbattere il mio xml in più colonne o semplicemente avere un blob gigante.Capisco che esiste un limite di dimensioni di 2 GB, tuttavia non ho dubbi sul raggiungimento di tale limite. C'è una sezione sulla granularità XML che ritengo abbia toccato la mia domanda, ma a dire il vero l'ho letta più volte e ancora non so da che parte andare. –

Se è logico avere una colonna per l'XML, allora dovresti fare proprio questo. Quanto menzionato nel link sulla granularità ha a che fare con l'impatto della divisione dell'XML su righe in cui una parte più piccola dei dati viene bloccata durante l'aggiornamento. L'utilizzo di più colonne non ha alcun effetto sul blocco. Il link menziona anche le ottimizzazioni quando si aggiorna parte dell'XML sia quando si utilizzano gli indici XML, sia quando non si deve suddividere le colonne su colonne non dovrebbe essere molto più veloce per gli aggiornamenti. –

Sì, è importante! Quando si archivia un blob XML di grandi dimensioni come datapype XML in SQL Server, non viene memorizzato come blob testuale, ma viene "analizzato" e "tokenizzato" e archiviato in modo significativamente più efficiente rispetto a quando si utilizza solo varchar(max) per archiviare il rappresentazione testuale.

Se assomiglia all'XML, odora XML e ciarlanda come XML, quindi utilizza decisamente il tipo di dati XML!

Aggiornamento: se si desidera archiviare e recuperare l'XML nel suo complesso, non vedo alcun vantaggio nel suddividerlo in blocchi. Il XML tipo di dati in SQL Server può contenere fino a 2 GByte dei dati (proprio come varchar(max)) e non sarà vedere alcun miglioramento delle prestazioni da memorizzare (e recuperare) multipli frammenti XML più piccoli.

fonte

2013-08-07 05:18:08

Sembra che la domanda non riguardi 'XML' rispetto ai tipi di stringhe, ma piuttosto _ un gigante XML_ vs _multiple [smaller] XML_ –

@ i-one Che è assolutamente corretto. –

@DanLing: ho aggiornato la mia risposta - se avete sempre intenzione di archiviare e recuperare l'intero blob XML in una singola operazione - nessun punto nell'avere tanti piccoli pezzi ... –

Se il campo sta per essere usato per memorizzare carichi applicativi e l'applicazione in grado di gestire correttamente versioning o future modifiche alla struttura poi vorrei andare con un campo xml. L'unico svantaggio di archiviare come XML è che le query possono richiedere più tempo rispetto ai dati appiattiti. Se le tue app gestiscono tutti i dati passati come xml, questo diventa un ostacolo più piccolo da saltare.

fonte

2013-08-07 03:01:24

Sì.

Si consiglia di utilizzare nvarchar (MAX) per memorizzare XML. Poiché, se (nel prossimo futuro) si prevede di modificarlo, modificare lo storage per mantenere json (invece di xml), quindi sarebbe molto flessibile mantenere Json per te. Ma se si sceglie di utilizzare XML Datatype, è rigido utilizzare solo XML. Tuttavia, come ha detto Mark, se assomiglia davvero all'XML, odora di XML e fa quack come XML, allora sicuramente USI il tipo di dati XML! E se il tuo caso di uso commerciale dice di inserire e recuperare l'intero XML in una sola volta, non vedo che ci siano molti vantaggi in termini di prestazioni nella suddivisione in blocchi.

fonte

2014-01-10 08:54:55

Progettazione della tabella per archiviare dati XML in SQL Server 2008 R2

risposta

Problemi correlati