Utilizzo di XML come archivio dati [chiuso]

Stavo pensando al formato XML e alla seguente citazione:

“XML non è un database. Non è mai stato pensato per essere un database. Non sarà mai un database. I database relazionali sono una tecnologia collaudata con oltre 20 anni di esperienza nell'implementazione. Sono prodotti solidi, stabili e utili. Non stanno andando via. XML è una tecnologia molto utile per spostare i dati tra database diversi o tra database e altri programmi. Tuttavia, non è esso stesso un database. Non usarlo come uno. “- XML efficace: 50 modi specifici per migliorare il tuo XML di Elliotte Rusty Harold (pagina 230, parte 4, articolo 41, secondo paragrafo)

Questo sembra davvero sottolineare che XML non dovrebbe essere usato per l'archiviazione dei dati e dovrebbe essere usato solo per l'interoperabilità tra i programmi.

Personalmente, non sono d'accordo e il app.configfile .NET utilizzato per archiviare le impostazioni di un programma è un esempio di archiviazione dei dati in un file XML. Tuttavia, per i database anziché le configurazioni, ecc. XML non deve essere utilizzato.

Per sviluppare il mio punto, userò due esempi:
A) Dati sui clienti con campi che sono tutti su un livello cioè che ci sono un numero di campi tutti relativi ad un cliente senza figli
B) Dati sulla configurazione di un'applicazione in cui campi nidificati e le proprietà hanno molto senso

Quindi la mia domanda è: questa è ancora una dichiarazione valida ed è ora accettabile archiviare i dati usando XML?

EDIT: ho inviato un'e-mail all'autore di quella citazione per chiedere il suo contributo / contesto extra.

Questa citazione non riguarda l'uso dell'XML come formato di archiviazione in generale (per il quale va bene, a seconda dei requisiti), ma per l' archiviazione di tipo database .

Quando le persone parlano di database, di solito significano sistemi di archiviazione che archiviano enormi quantità di dati, spesso nell'intervallo di gigabyte o terabyte. Un database è potenzialmente molto più grande della quantità di RAM disponibile sul server che lo memorizza. Dal momento che nessuno ha mai bisogno di tutti i dati in un database contemporaneamente, i database dovrebbero essere ottimizzati per il recupero rapido di sottoinsiemi selettivi dei loro dati: questo è l' SELECTistruzione per questo, e i database relazionali e le soluzioni NoSQL ottimizzano il loro formato di archiviazione interno per una rapida recupero di tali sottoinsiemi.

XML, tuttavia, non soddisfa davvero questi requisiti. A causa della sua struttura di tag nidificata, è impossibile determinare dove nel file è memorizzato un certo valore (in termini di offset di byte in un file) senza percorrere l'intero albero del documento, almeno fino alla corrispondenza. Un database relazionale ha indici e cercare un valore in un indice, anche con un'implementazione di ricerca binaria primitiva, è una singola ricerca O (log n), e poi raggiungere i valori effettivi non è altro che una ricerca di file (ad es. fseek(data_file_handle, row_index * row_size)), che è O (1). In un file XML, il modo più efficiente è quello di eseguire un parser SAX sul tuo documento, facendo moltissime letture e ricerche prima di arrivare ai tuoi dati reali; difficilmente puoi ottenerlo meglio di O (n), a meno che tu non usi gli indici, ma poi, dovresti ricostruire l'intero indice per ogni inserimento (vedi sotto).

L'inserimento è anche peggio. I database relazionali non garantiscono l'ordine delle righe, il che significa che possono semplicemente aggiungere nuove righe o sovrascrivere le righe contrassegnate come "eliminate". Questo è estremamente veloce: il DB può semplicemente mantenere un pool di posizioni scrivibili; ottenere una voce dal pool è O (1) a meno che il pool non sia vuoto; nel peggiore dei casi, il pool è vuoto e deve essere creata una nuova pagina, ma anche questo è O (1). Al contrario, un database basato su XML dovrebbe spostare tutto dopo il punto di inserimento per fare spazio; questo è O (n). Quando gli indici entrano in gioco, le cose diventano ancora più interessanti: gli indici tipici del database relazionale possono essere aggiornati con una complessità relativamente bassa, diciamo O (log n); ma se vuoi indicizzare i tuoi file XML, ogni inserimento potenzialmente modifica la posizione su disco di ogni valore nel documento, quindi deviricostruire l'intero indice . Questo vale anche per gli aggiornamenti, poiché l'aggiornamento, diciamo, del contenuto testuale di un elemento, può cambiare la sua dimensione, il che significa che l'XML consecutivo deve cambiare. Un database relazionale non deve assolutamente toccare l'indice se si aggiorna una colonna non indicizzata; un database XML dovrebbe ricostruire l'intero indice per ogni aggiornamento che modifica la dimensione del nodo XML aggiornato.

Questi sono gli aspetti negativi più importanti, ma ce ne sono altri. XML è molto dettagliato, il che è utile per le comunicazioni da server a server, perché aggiunge sicurezza (il server ricevente può eseguire tutti i tipi di controlli di integrità sull'XML e se qualcosa è andato storto nel trasferimento, è improbabile che il documento venga convalidato ). Per l'archiviazione di massa, tuttavia, questo sta uccidendo: non è raro avere un overhead del 100% o più per i dati XML (non è raro vedere rapporti di overhead nell'intervallo del 1000% per cose come i messaggi SOAP), mentre un tipico archivio DB relazionale gli schemi hanno solo un sovraccarico costante per i metadati della tabella, più un piccolo bit per riga; la maggior parte dell'overhead nei database relazionali proviene da larghezze di colonna fisse. Se hai un terabyte di dati, un overhead del 500% è semplicemente inaccettabile, per molte ragioni.

XML è pessimo per l'archiviazione dei dati. Innanzitutto, è molto prolisso. I dati memorizzati in un file XML occuperanno molto più spazio su disco rispetto agli stessi dati archiviati in qualsiasi ragionevole sistema di database. In un record XML, il nome di un determinato campo verrà archiviato due volte, insieme alla rappresentazione in formato stringa dei dati. Quindi, per esempio, per memorizzare un singolo integar in un campo chiamato "foobar", si finisce con questa stringa di 19 byte:

<foobar>42</foobar>

D'altra parte, un vero database lo memorizzerà come un singolo valore intero, prendendo 4 byte. Se il tuo database è piccolo, ciò non significa molto, ma se hai 10.000 record, questo è un problema.

In secondo luogo, un XML deve essere analizzato dal testo ogni volta che il file viene letto. Per il campo sopra, un vero database legge semplicemente i dati binari in memoria dall'offset in cui sa di aver memorizzato il campo "foobar". Se il file è archiviato come XML, deve leggere il campo "foobar", analizzare quel testo , determina quale campo è, quindi analizza la stringa "42" e convertila nel 42 binario.

Pertanto, le penalità prestazionali per l'utilizzo di XML sono enormi. I vantaggi di XML sono che è in qualche modo leggibile dall'uomo e che consente un facile trasferimento di dati tra sistemi completamente separati. Nessuno di questi vantaggi si applica per un database locale.

L'unica eccezione sono i file di configurazione, che sono generalmente piccoli e generalmente devono essere modificabili dall'uomo.

Un database XML sarà assolutamente più grande e più lento di qualsiasi ragionevole sistema SQL. A meno che non sia possibile trovare un vantaggio di controbilanciamento nella leggibilità o interoperabilità umana, non ha senso utilizzarlo per l'archiviazione dei dati.

XML è praticabile a seconda del contesto. Se i tuoi dati sono piuttosto statici e non cambiano molto (ad esempio i dati di esempio), sì XML è un buon uso.

Le impostazioni di configurazione, i dati di esempio (anche se sono milioni di righe, ma cambiano raramente), sono tutti buoni usi dell'XML.

Le operazioni di lettura / scrittura del disco rigido sono costose, molto più che accedere ai dati da uno stack Oracle / Sql.

Questo sembra davvero sottolineare che XML non dovrebbe essere usato per l'archiviazione dei dati e dovrebbe essere usato solo per l'interoperabilità tra i programmi.

La tua premessa è difettosa.

Il paragrafo che citi in realtà dice che XML non è un sostituto di un database , non che non dovrebbe essere usato per l'archiviazione dei dati .

È chiaro che un file di impostazioni non è la stessa cosa di un database e quindi è possibile (e dovrebbe?) Utilizzare diverse tecnologie.

Correggimi se sbaglio, ma sembra che tu abbia più esperienza con i linguaggi di markup rispetto ai database. Se hai un po 'di esperienza con i database, ti accorgeresti a quali domini sono adatte le due diverse tecnologie.

Questo è davvero soggettivo. Quella citazione è, come, l'opinione di qualcuno, amico.

Onestamente, penso che XML sia una valida alternativa a un database in quanto presenta molteplici vantaggi rispetto a un RDMS, incluso un basso sovraccarico, che equivale a uno storage più economico (soprattutto quando si utilizza un servizio di hosting che addebita i database separatamente).

Dai un'occhiata a dasBlog e BlogEngine . Entrambe queste applicazioni usano xml come memoria di default.

Detto ciò. Non è un RDMS e se hai un'alta volatilità (molti aggiornamenti, inserimenti o eliminazioni) nei tuoi dati o richiedi un'alta disponibilità, usa un database. XML va bene per la memorizzazione di piccole cose come dati di configurazione e dati a bassa volatilità.

la mia domanda è: questa è ancora una dichiarazione valida ed è ora accettabile archiviare i dati usando XML?

Vedo il tuo punto nel tuo esempio sui file di configurazione di .NET. Tuttavia, qualsiasi altro formato di file avrebbe potuto essere utilizzato. In effetti, ai vecchi tempi, tali impostazioni venivano archiviate in normali file di testo chiamati file INI.

Vedo che la dichiarazione che hai presentato in grigio è valida e corretta se definisci un database come sistema software.

La definizione di XML in XML-Definition afferma che "(XML) è un linguaggio di markup che definisce un insieme di regole per la codifica dei documenti in un formato che è sia leggibile dall'uomo che leggibile dalla macchina".

Questa definizione si concentra sulla leggibilità e sul linguaggio piuttosto che sui meccanismi di gestione dei dati.

Rispetto a un RDBMS, XML non fornisce mezzi per inserire ed eliminare casualmente le righe in un file XML. Ad esempio, se si dispone di 1000000 righe e si desidera eliminare le righe in modo casuale anche in un singolo ambiente utente, il file basato su XML non sarebbe una buona scelta per un database. Inoltre, XML non fornisce alcun meccanismo nativo per bloccare i dati. Infatti, poiché XML non è un software, tutte le proprietà ACID (atomicità, coerenza, isolamento, durabilità) che garantiscono che le transazioni del database siano elaborate in modo affidabile in un ambiente condiviso sono lasciate allo sviluppatore per la costruzione (ad eccezione della durabilità). XML non ha una specifica solida per gestire l'integrità dei dati tra i file XML, per non parlare di server diversi (ad es. File xml del cliente e file xml degli ordini - Nessun FK per far rispettare l'integrità).

Quanto sopra non è un elenco di ciò che manca a XML, ma potrebbe essere un server come una rapida giustificazione dell'affermazione che XML non è un software di database .

XML non ha mai voluto essere un database o sostituirlo.

L'XML è definito principalmente per i documenti Web che allows for the creation of customized tags for individual information fields., tuttavia, non otterresti mai una gestione dei dati centralizzata relazionale con esso.

Perché dovresti effettivamente utilizzare XML per archiviare i dati in primo luogo? Voglio dire, dopo tutto è una lingua ...

Mentre si potrebbe sostenere che si tratta di un formato flessibile e di facile comprensione, ciò si applica solo quando è necessario apportare modifiche manuali ai file. Quando interagisci effettivamente con il database con un'interfaccia comune (recupera i dati X che soddisfano i requisiti Y e Z, archivia / aggiorna i dati X, ...) tali vantaggi diventano nulli.

Risposta breve: dipende.

Risposta lunga: Dal mio punto di vista ciò dipende fortemente dalla quantità di dati che si desidera archiviare. Ad esempio se hai un paio di oggetti nella tua applicazione durante il runtime e vuoi archiviarli dopo aver eseguito lo strumento, un file XML va benissimo. Tuttavia, se il tuo negozio online ha 5000 clienti e ancora più ordini, un database sarebbe una memoria di dati più appropriata.

Inoltre, penso che archiviare le impostazioni in un database e non in un file come app.config nella maggior parte dei casi non sia molto utile, ma non credo che questo esempio dimostri che la citazione è sbagliata.

XML è una scelta eccellente per le impostazioni di configurazione. Non solo i file XML sono facili da analizzare / evidenziare in un IDE, ma sono anche molto facili da modificare per i non programmatori. Li trovo incredibilmente utili negli scenari di sviluppo web in cui le attività di manutenzione vengono eseguite da designer e gestori di contenuti.

L'XML in genere non deve essere utilizzato come fonte di dati primaria per applicazioni non banali. Il solo sovraccarico di serializzazione / deserializzazione richiede una soluzione diversa.

Il termine database può riferirsi solo ai dati non elaborati o anche al sistema di gestione del database. Questa definizione fa una grande differenza nell'intero argomento.

Se usiamo la definizione RDBMS, allora XML ha molto poco in questo senso. Ottieni pochissimo in termini di garanzie ACID (dovresti scrivere il tuo codice per realizzarle). Se hai bisogno di questi (e la maggior parte dei sistemi transazionali lo fanno), sei già nei guai principali. Potrei dare un elenco di centinaia di funzionalità che sono date per scontate con RDBMS, che dovresti reinventare e reimplementare. Pensa a modelli di sicurezza, replica, backup, solo per citarne alcuni di base.

Nel senso sopra, no, XML non è un database e non dovresti provare a usarlo come tale.

Se utilizziamo la definizione di "dati non elaborati", le tariffe XML sono molto migliori, ma comunque non eccezionali. Come altri hanno sottolineato, tuttavia è estremamente dettagliato in generale, in genere privo di codifica binaria e con tag duplicati, ecc. Questi sono compromessi fatti in modo che XML possa essere leggibile dall'uomo - in sostanza, l'efficienza è nemica di questo requisito . L'XML non è particolarmente adatto anche alle situazioni più semplici in cui si inseriscono continuamente record. Supponendo che tu voglia che il tuo file XML sia valido, hai bisogno di un singolo tag di chiusura, il che significa che aggiungere un record significa che devi spostare i tag alla fine. Questo è piuttosto costoso (come facciamo a sapere dove inizia quel tag? Cosa succede se ci sono più "tabelle", spostiamo semplicemente l'intero file?) E se vuoi aggirarlo, tu '

Ci sono situazioni in cui XML è appropriato: i file di configurazione sono un ottimo esempio, perché sono in genere piccoli e la leggibilità umana è una caratteristica eccellente da avere. Avere un database solo per un file di configurazione potrebbe essere eccessivo.

I database, d'altra parte, sono eccellenti quando si hanno migliaia (o milioni / miliardi) di record e molti utenti lo aggiornano contemporaneamente. Quindi sì, XML non è un database e non dovresti usarlo come tale. Il tuo esempio sembra essere una di quelle situazioni in cui non hai bisogno di un DB in primo luogo e XML è la soluzione migliore.

Per come la vedo io è questa: se usi XML come DB (diciamo, come backing store per un sistema transazionale), finirai per reinventare e riscrivere un RDBMS . Questo è un modo davvero scarso di spendere tempo ed energie. Penso che sia quello che diceva anche quella citazione.

Sono d'accordo che non è un database relazionale. Penso che l'autore stia semplicemente dicendo nella citazione di non usarlo come uno.

Detto questo, anche se potresti averne bisogno o meno. Se in realtà non è necessario eseguire molte query sui dati e si intende solo archiviarli e recuperarli in seguito in base ad alcuni criteri di query limitati, è necessario archiviare e recuperare XML DOCUMENT, non un database relazionale.

Esistono molte applicazioni che devono semplicemente archiviare un documento con i dati al suo interno per il recupero completo in un secondo momento. In questo caso, è inutile creare uno schema basato su SQL, analizzare l'XML e quindi serializzarlo nel database solo per fare il contrario in seguito. C'è un sacco di overhead di codice potenzialmente coinvolto nel farlo. C'è meno però se lo fai bene.

Puoi utilizzare strumenti ORM come Hibernate e strumenti come Apache Axis per generare automaticamente praticamente tutto il codice necessario per creare un servizio che gestisca semplicemente semplici operazioni CRU. Dovresti ovviamente includerlo nell'autenticazione, e forse potresti voler separare i dati in base all'utente, al livello di accesso, ecc. Potresti anche voler limitare le operazioni che un determinato utente è autorizzato a fare tramite il servizio SOAP per esempio.

In questo senso stai facendo più come la gestione dei contenuti che altro.