Quali sono i vantaggi dell'archiviazione di xml in un database relazionale?

Nella mia esperienza, i dati XML sono solitamente archiviati e interrogati raramente, ma spesso estratti quando necessario, di solito quando altri sistemi richiedono una rappresentazione XML di alcuni dati che possono essere difficili o impossibili da generare al volo da relazionali dati. I dati XML potrebbero essere pre-compilati da qualche altro processo.

Se riesci a immaginare di archiviare i tuoi dati in un flusso binario in un blob, allora immagino che puoi immaginare di archiviare i tuoi dati in un formato xml in un blob.

Naturalmente, molte cose sono meglio lasciate nella fantasia dell'immaginario.

Dì, cartelle mediche elettroniche per esempio:

Dato che molto probabilmente si memorizza l'ASCII HL7 V2.x in un campo in un database. Probabilmente sarai 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 lo fa. Abbiamo dati che devono essere elaborati più volte, memorizzati in relazione. Tuttavia, l'elaborazione avviene in Java, ed è più facile lavorare con XML lì. Quindi, eseguiamo un passaggio una tantum attraverso i dati relazionali e li memorizziamo come XML in una tabella. Quindi possiamo elaborare quei dati in Java con una query di non-join piuttosto che recuperare i dati ogni volta e 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 viste dell'applicazione è serializzato e memorizzato nel database e non è necessario eseguire query sull'XML. Per stato dell'interfaccia utente intendo, ordina l'ordine di visualizzazione, la dimensione delle finestre ecc.

Spesso ottieni dati misti che sono sia XML che relazionali. (Un bell'esempio di questo è un negozio di 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. Memorizza i dati in due DB separati, XML in XML nativo e metadati in relazionale.

L'opzione 3 è probabilmente la più pulita, ma anche la più costosa e la più difficile da implementare, in più non vuoi 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 poveri nella gestione dei dati relazionali (che è più probabile che vengano utilizzati nelle ricerche) e la tecnologia è complessivamente meno matura del DB relazionale.

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

Secondo la mia esperienza, l'uso di XML in un database finisce per essere perché è così che l'origine dei dati lo memorizza o lo si aggiunge a un database esistente per estendere le funzionalità in un modo che non richiede un sacco di database programmazione da supportare.

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

Spero che questo aiuti, Jeff

I datastore orientati ai documenti (noti anche come NoSql) sono molto popolari in questi giorni:

link

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

Per un lungo periodo, se si voleva utilizzare lo storage orientato ai documenti, l'unica scelta era spingere i dati strutturati (come XML) in una grande colonna. I database relazionali hanno aggiunto funzionalità come l'indicizzazione e la corrispondenza per supportarlo.

Contrastate ciò con Mongo, dove solo cosa nel database sono i documenti. Ma questo è un altro argomento.

EDIT: l'idea centrale dell'orientamento al documento è: estrai i dati, li manipoli e li rimandi completamente. A volte, come quando stai trasmettendo il documento al cliente, vuoi semplicemente mandare tutto come un blob e lasciarglielo occupare. Il vantaggio (e l'inconveniente) è la flessibilità. La convalida e la correttezza del documento vengono eseguite all'esterno del database.

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

Quali sono i vantaggi dell'archiviazione di un albero (XML) in un elenco di tuple (una tabella di database)?

Non c'è alcun motivo per cui XML non dovrebbe essere interrogabile dal tuo DBMS usando ad es. XPath o SPARQL.

Come vedo, sono semplicemente due diverse strutture di dati. E non c'è motivo per cui non dovrebbero essere incorporati l'uno nell'altro.

È possibile 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, è ancora più valida la validazione.

Bene, XML (o JSON) è piuttosto buono per memorizzare i metadati con la gerarchia. Quali sono le alternative? Una tabella di metadati con refid / chiave / valore / profondità forse? È un po 'macchinoso (ma probabilmente è meglio per l'interrogazione se è necessario farlo). Memorizzare alcuni dati xml su un documento (una riga in una tabella di documenti) è piuttosto comodo quando si desidera archiviare alcune informazioni gerarchiche senza dover fare affidamento su una tabella esterna o dover aggiungere 1 colonna per "tipo" di informazioni.

Direi che è una cattiva pratica in quanto si sta intasando lo storage altrimenti efficiente con tag inefficienti che non devono essere presenti se si prende lo sforzo di analizzare le informazioni. XML ha un overhead di memoria orribile rispetto ai dati che descrive, in quanto è necessario un tag per ogni colonna per ogni riga. Per confronto, i dati analizzati e archiviati in formato relazionale hanno il nome della colonna memorizzato UNA VOLTA. Per una dozzina di righe su un dev. box, grande affare, ma ho visto gli sviluppatori fare l'ipotesi che questo è scalabile a milioni di righe. Questo può rappresentare i 100 di GB di overhead per alcune decine di GB di dati, il che crea sfide operative. Stai praticamente abdicando la responsabilità da te stesso e spingi sulle persone che devono sostenere la schifezza che hai scritto.

Quindi, perché non memorizzarlo VIA dai dati operativi, nel proprio database? O come è inteso - in file flat? Probabilmente non verrà mai più esaminato, quindi perché non rimuoverlo dal colpire le prestazioni di un sistema operativo? Ricorda che XML è SOLO lì 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 suo punto, non c'è nulla di intelligente in proposito. Memorizzando 10 volte la quantità di overhead per una determinata quantità di dati, si dice semplicemente che si tratta di uno sviluppatore sciatto che non ha pensato a cose e non può essere utilizzato per elaborare i dati che si stanno consumando in un formato ragionevole, efficiente, veloce per la query. Smetti di spingere i tuoi sforzi sul supporto operativo e PENSA su come gestire meglio i dati dopo averli ricevuti sarebbe la mia chiamata. Non c'è difesa per la memorizzazione dei dati come XML dopo che è stato ricevuto, poiché è servito allo scopo.