Quali sono i vantaggi della memorizzazione di xml in un database relazionale?

Stavo frugando nel database AdventureWorks oggi e ho notato che un numero di tabelle ( HumanResources.JobCandidatee Sales.Individualad esempio) hanno una colonna che memorizza i dati XML.

Quello che vorrei sapere è, qual è il vantaggio di memorizzare fondamentalmente i dati di una riga della tabella del database nella colonna di un'altra tabella? Questo non rende difficile interrogare queste informazioni? Oppure si presume che i dati non debbano essere interrogati e debbano solo essere archiviati?

Poiché non tutti i dati devono essere archiviati in modo relazionale e scrivere codice per elaborare i dati che sono stati passati come XML per l'archiviazione relazionale richiede tempo (e molto molto noioso). Ciò è particolarmente vero quando molti dati XML provengono da sistemi che generano grandi risposte generiche.

Ho visto spesso situazioni in cui un messaggio viene ricevuto da un altro sistema e non ci interessa circa il 98% di ciò che contiene. Quindi lo analizziamo per suddividere il 2% che ci interessa, archiviarlo relazionalmente e quindi archiviare l'intero messaggio nel caso in cui avessimo bisogno del rimanente 98% in seguito.

E SQL Server ti offre alcuni strumenti e sintassi OK per lavorare con XML in T-SQL, quindi non è come se fosse totalmente al di fuori della portata pratica per le query ad hoc nel modo in cui potrebbe essere se tu stessi archiviando, diciamo, i contenuti di un CSV.

E questo esclude la possibilità che ciò che si desidera effettivamente archiviare sia XML (ad esempio per scopi di supporto e debug) ...

Se il formato dei dati è volatile ed è soggetto a possibili modifiche, si consiglia di metterlo insieme come XML e inserirlo nel database in questo modulo, evitando così future modifiche allo schema del database.

Allo stesso modo, se i dati vengono forniti da un sistema esterno e consumati di nuovo da esso e non sono in grado di fornirti un formato permanente, è quello che faresti.

Questo non rende difficile interrogare queste informazioni?

SQL Server può eseguire query su campi e variabili XML. Non necessariamente difficile, ma più lavoro, sì. Ma fattibile.

Nella mia esperienza, i dati XML sono generalmente archiviati e raramente interrogati, ma spesso estratti quando necessario, di solito quando un altro sistema ha bisogno di una rappresentazione XML di alcuni dati che può essere difficile o impossibile da generare al volo da dati relazionali. I dati XML potrebbero essere precompilati da altri processi.

Se riesci a immaginare di archiviare i tuoi dati in un flusso binario in un BLOB, immagino che tu possa immaginare di archiviare i tuoi dati in un formato XML in un BLOB.

Naturalmente, molte cose sono meglio lasciare nell'immaginazione dell'immaginatore.

Diciamo, ad esempio, cartelle cliniche elettroniche:

Poiché molto probabilmente memorizzeresti ASCII HL7 V2.x in un campo in un database. Probabilmente saresti in grado di memorizzare HL7 V3.0 in un campo in un database.

Quindi il vantaggio è la convenienza.

Attualmente sto lavorando a un progetto che fa questo. Abbiamo dati che devono essere elaborati più volte, archiviati in modo relazionale. Tuttavia, l'elaborazione viene eseguita in Java ed è più facile lavorare con XML lì. Quindi, eseguiamo un unico passaggio attraverso i dati relazionali e li memorizziamo come XML in una tabella. Quindi possiamo elaborare quei dati in Java con una query senza join anziché recuperarli ogni volta, ed elaborare gli stessi dati più e più volte sul contenuto del nostro cuore. È molto più semplice ed efficiente.

Un buon esempio di archiviazione di XML è quando si desidera mantenere gli stati dell'interfaccia utente nel database. Lo stato di tutte le visualizzazioni dell'applicazione è serializzato e memorizzato nel database e non è necessario interrogare l'XML. Per stato dell'interfaccia utente intendo, ordinare l'ordine di visualizzazione, le dimensioni delle finestre, ecc.

Spesso si ottengono dati misti che sono sia XML che relazionali. (Un ottimo esempio di ciò è un archivio documenti in cui ogni documento può avere campi di metadati come titolo, data di creazione, proprietario e così via.)

A questo punto devi scegliere tra tre opzioni:

1. Archivia tutto in un DB relazionale.
2. Archivia tutto in un DB XML nativo.
3. Archivia i dati in due DB separati, XML in XML nativo e metadati in relazione.

L'opzione 3 è probabilmente la più pulita, ma anche la più costosa e la più difficile da implementare, inoltre non si desidera necessariamente transazioni distribuite in un sistema non molto grande. L'opzione 2 non è molto buona in quanto i database XML nativi sono in genere estremamente scarsi nella gestione dei dati relazionali (che è più probabile che tu utilizzi nelle ricerche) e la tecnologia è nel complesso meno matura del DB relazionale.

Questo ti lascia con l'opzione 1 come certamente non la soluzione migliore ma forse la meno cattiva.

Nella mia esperienza, l'uso di XML in un database finisce per essere perché è così che l'origine dei dati lo memorizza, o lo stai aggiungendo a un database esistente per estendere le funzionalità in un modo che non richiederà molta programmazione del database per supportare .

Se stai cercando frequentemente i nuovi dati, potrebbe avere senso dividere l'XML nelle sue parti componenti. In caso contrario, può essere un modo utile per salvare i dati modificati di rado.

Spero che questo aiuti, Jeff

I datastore orientati ai documenti (alias NoSql) sono molto popolari in questi giorni:

http://en.wikipedia.org/wiki/Document-oriented_database

Non c'è motivo per cui non è possibile utilizzare uno schema orientato ai documenti in un database relazionale. Potresti non ottenere tutti gli stessi benefici rispetto a qualcosa come Mongo, ma non avrai nemmeno gli svantaggi.

Per molto tempo, se si voleva utilizzare l'archiviazione orientata ai documenti, l'unica scelta era inserire i dati strutturati (come XML) in una grande colonna. I database relazionali hanno aggiunto funzionalità come l'indicizzazione e la corrispondenza per supportarlo.

In contrasto con Mongo, dove l' unica cosa nel database sono i documenti. Ma questo è un altro argomento.

EDIT: l'idea di base orientata al documento è: estrarre i dati, manipolarli e rimandarli indietro nel loro insieme. A volte, come quando si sta trasmettendo il documento al client, si desidera semplicemente inviare tutto come un blob e lasciarlo gestire. Il vantaggio (e l'inconveniente) è la flessibilità. La convalida e la correttezza del documento vengono eseguite all'esterno del database.

EDIT EDIT: un altro contrasto. Immagina di salvare immagini JPG o documenti di Word in una colonna del database.

Quali sono i vantaggi della memorizzazione di un albero (XML) in un elenco di tuple (una tabella di database)?

Non vi è alcun motivo per cui l'XML non debba essere interrogabile dal proprio DBMS utilizzando ad esempio XPath o SPARQL.

A mio avviso, sono semplicemente due diverse strutture di dati. E non vi è alcun motivo per cui non dovrebbero essere integrati l'uno nell'altro.

Puoi cercare i motivi per cui il tipo di dati JSON è stato aggiunto in PostgreSQL. Penso che si applichino molti degli stessi argomenti. Tranne che con XML / XSD, è possibile una convalida ancora maggiore.

Bene, XML (o JSON) è abbastanza buono per archiviare metadate con gerarchia. Quali sono le alternative? Una tabella di metadati con refid / chiave / valore / profondità forse? È un po 'ingombrante (ma probabilmente migliore per le query se è necessario farlo). La memorizzazione di alcuni dati XML su un documento (una riga in una tabella di documenti) è piuttosto conveniente quando si desidera memorizzare alcune informazioni gerarchiche senza fare affidamento su una tabella esterna o aggiungere 1 colonna per "tipo" di informazioni.

Direi che è stata una cattiva pratica in quanto intasare l'archiviazione altrimenti efficiente con tag inefficienti che non devono essere presenti se si prende lo sforzo di analizzare le informazioni. XML ha un overhead di archiviazione orribile rispetto ai dati che descrive, poiché è necessario un tag per ogni colonna per ogni riga. In confronto, i dati analizzati e archiviati in formato relazionale hanno il nome della colonna memorizzato ONCE. Per una dozzina di file su uno sviluppatore. scatola, un grosso problema, ma ho visto gli sviluppatori supporre che sia scalabile a milioni di righe. Questo può rappresentare 100 di GB di sovraccarico per alcune decine di GB di dati, il che crea sfide operative. Fondamentalmente stai rinnegando la responsabilità da te stesso e spingendo verso le persone che devono sostenere la merda che hai scritto.

Quindi, perché non memorizzarlo LONTANO dai dati operativi, nel proprio database? O come previsto - in file flat? Probabilmente non verrà mai più esaminato, quindi perché non rimuoverlo dal colpire le prestazioni di un sistema operativo? Ricorda che XML è presente SOLO per fornire una descrizione dello schema di dati che altrimenti non sarebbe evidente a causa delle differenze del protocollo di archiviazione tra i sistemi. Questo è il punto, non c'è niente di intelligente. Memorizzare 10 volte la quantità di overhead per una determinata quantità di dati dice solo che sei uno sviluppatore sciatto che non ha pensato alle cose e che non può essere elaborato per elaborare i dati che stai consumando in un formato ragionevole, efficiente e veloce da interrogare. Smetti di spingere i tuoi sforzi sul supporto operativo e PENSA a come puoi gestire meglio i dati dopo ho ricevuto sarebbe la mia chiamata. Non vi è alcuna difesa per l'archiviazione dei dati come XML dopo che sono stati ricevuti, poiché è servito al suo scopo.