Utilizarea XML ca stocare de date [închis] (Inginerie software, Bază De Date, Proiectarea Bazei De Date, Xml)

Kian a intrebat.
a intrebat.

Mă gândeam la formatul XML și la următorul citat:

„XML nu este o bază de date. Nu a fost niciodată menit să fie o bază de date. Nu va fi niciodată o bază de date. Bazele de date relaționale sunt o tehnologie dovedită, cu o experiență de peste 20 de ani de implementare. Sunt produse solide, stabile și utile. Ele nu vor dispărea. XML este o tehnologie foarte utilă pentru mutarea datelor între diferite baze de date sau între baze de date și alte programe. Cu toate acestea, nu este în sine o bază de date. Nu o folosiți ca pe una”. -Effective XML: 50 de modalități specifice de îmbunătățire a XML-ului dumneavoastră de Elliotte Rusty Harold (pagina 230, partea 4, punctul 41, al doilea paragraf)

Acest lucru pare să sublinieze cu adevărat faptul că XML nu ar trebui să fie folosit pentru stocarea datelor și ar trebui să fie folosit doar pentru interoperabilitatea între programe.

Personal, nu sunt de acord, iar .NET’s app.config care este utilizat pentru a stoca setările unui program este un exemplu de stocare de date într-un fișier XML. Cu toate acestea, pentru baze de date, mai degrabă decât pentru configurații etc., XML nu ar trebui să fie utilizat.

Pentru a-mi dezvolta punctul de vedere, voi folosi două exemple:
A) Date despre clienți cu câmpuri care sunt toate pe un singur nivel, adică există un număr de câmpuri care se referă toate la un client fără copii.
B) Date despre configurația unei aplicații în care câmpurile și proprietățile imbricate au mult sens.

Așadar, întrebarea mea este: mai este aceasta o afirmație valabilă și este acceptabilă stocarea datelor folosind XML?

EDIT: Am trimis un e-mail autorului acestui citat pentru a-i cere părerea/contextul suplimentar.

Comentarii

  • O bază de date nu înseamnă stocarea date, ci obținerea date pe un anumit criteriu. XML pur și simplu nu se adaptează – încercați să manipulați un fișier XML de 100 GB cu datele pe care le descrieți. – utilizator1249
  • Întrebarea este neclară. Întrebați despre stocarea datelor într-un fișier XML în locul unei baze de date sau despre stocarea datelor în interiorul unei baze de date, dar ca tip XML. Mai mult încurcă și mai mult exemplul fișierului de configurare .net, deoarece nu îl văd ca fiind stocare de date. –  > Por softveda.
  • Nimeni nu a menționat încă faptul că nici un format de stocare a datelor nu este în sine o bază de date. O bază de date include un format de stocare și un mecanism de regăsire. XML nu este un mecanism de regăsire, deci nu poate fi o bază de date. XML este, de asemenea, un format de stocare teribil pentru mai mult de 1 MB de date. –  > Por GlenPeterson.
12 răspunsuri
tdammers

Acest citat nu se referă la utilizarea XML ca format de stocare în general (pentru care este în regulă, în funcție de cerințe), ci pentru baza de date-de stocare de tip bază de date.

Când oamenii vorbesc despre baze de date, de obicei se referă la sisteme de stocare care stochează uriașe cantități uriașe de date, adesea de ordinul gigabytelor sau terabytelor. O bază de date este potențial mult mai mare decât cantitatea de memorie RAM disponibilă pe serverul care o stochează. Deoarece nimeni nu are nevoie niciodată de toate datele dintr-o dată într-o bază de date, bazele de date ar trebui să fie optimizate pentru recuperarea rapidă a unor subseturi selective din datele lor: aceasta este ceea ce se numește SELECT declarație, iar bazele de date relaționale, precum și soluțiile NoSQL își optimizează formatul de stocare internă pentru recuperarea rapidă a unor astfel de subseturi.

Cu toate acestea, XML nu se potrivește cu adevărat acestor cerințe. Din cauza structurii sale de etichete imbricate, este imposibil să se determine unde este stocată o anumită valoare în fișier (în termeni de offset de octeți în fișier) fără a parcurge întregul arbore al documentului, cel puțin până la potrivire. O bază de date relațională are indici, iar căutarea unei valori într-un indice, chiar și cu o implementare primitivă de căutare binară, este o singură căutare O(log n), iar apoi, pentru a ajunge la valorile efective, nu este nevoie decât de o căutare în fișier (de exemplu, o căutare de tip „file-seek”). fseek(data_file_handle, row_index * row_size)), care este O(1). Într-un fișier XML, cel mai eficient mod este să rulați un analizor SAX peste document, efectuând o mulțime de citiri și căutări înainte de a ajunge la datele reale; cu greu puteți obține un rezultat mai bun decât O(n), cu excepția cazului în care utilizați indici, dar atunci ar trebui să reconstruiți întregul indice la fiecare inserție (a se vedea mai jos).

Inserarea este chiar mai rău. Bazele de date relaționale nu garantează ordinea rândurilor, ceea ce înseamnă că se pot adăuga rânduri noi sau se pot suprascrie rândurile marcate ca fiind „șterse”. Acest lucru este extrem de rapid: baza de date poate păstra o rezervă de locații inscriptibile; obținerea unei intrări din rezervă este O(1), cu excepția cazului în care rezerva este goală; în cel mai rău caz, rezerva este goală și trebuie creată o nouă pagină, dar și aceasta este O(1). În schimb, o bază de date bazată pe XML ar trebui să mute totul după punctul de inserție pentru a face loc; acest lucru este O(n). Atunci când intră în joc indexurile, lucrurile devin și mai interesante: indexurile tipice ale bazelor de date relaționale pot fi actualizate cu o complexitate relativ scăzută, de exemplu O(log n); dar dacă doriți să indexați fișierele XML, fiecare inserție poate schimba locația pe disc a fiecărei valori din document, astfel încât trebuie să să reconstruiți întregul index. Acest lucru este valabil și pentru actualizări, deoarece actualizarea, să zicem, a conținutului textului unui element, poate schimba dimensiunea acestuia, ceea ce înseamnă că XML-ul consecutiv trebuie să se schimbe. O bază de date relațională nu trebuie să se atingă deloc de index dacă se actualizează o coloană neindexată; o bază de date XML ar trebui să reconstruiască întregul index pentru fiecare actualizare care modifică dimensiunea nodului XML actualizat.

Acestea sunt cele mai importante dezavantaje, dar mai sunt și altele. XML este foarte verbos, ceea ce este bine pentru comunicarea între servere, deoarece adaugă siguranță (serverul care primește poate efectua tot felul de verificări de integritate asupra XML, iar dacă ceva nu a mers bine în timpul transferului, este puțin probabil ca documentul să fie validat). Cu toate acestea, pentru stocarea în masă, acest lucru este ucigător: nu este neobișnuit să ai un overhead de 100% sau mai mult pentru datele XML (nu este neobișnuit să vezi rapoarte de overhead în intervalul de 1000% pentru lucruri precum mesajele SOAP), în timp ce schemele tipice de stocare în baze de date relaționale au doar un overhead constant pentru metadatele tabelelor, plus un pic pe rând; cea mai mare parte a overhead-ului în bazele de date relaționale provine din lățimile fixe ale coloanelor. Dacă aveți un terabyte de date, o suprataxă de 500% este pur și simplu inacceptabilă, din mai multe motive.

Robotul Gort

XML este prost pentru stocarea datelor. În primul rând, este foarte verbos. Datele stocate într-un fișier XML vor ocupa mult mai mult spațiu pe disc decât aceleași date stocate în orice sistem de baze de date rezonabil. Într-o înregistrare XML, numele unui anumit câmp va fi stocat de două ori, împreună cu reprezentarea în șir de caractere a datelor. Astfel, de exemplu, pentru a stoca un singur integar într-un câmp numit „foobar”, se obține acest șir de 19 octeți:

<foobar>42</foobar>

Pe de altă parte, o bază de date reală va stoca acest lucru ca o singură valoare integar, ocupând 4 octeți. Dacă baza dvs. de date este mică, acest lucru nu înseamnă prea mult, dar dacă aveți 10 000 de înregistrări, este o problemă.

În al doilea rând, un XML trebuie să fie analizat din text de fiecare dată când fișierul este citit. Pentru câmpul de mai sus, o bază de date reală citește pur și simplu datele binare în memorie de la offset-ul în care știe că a stocat câmpul „foobar”. Dacă fișierul este stocat în format XML, trebuie să citească câmpul „foobar”, să analizeze textul, să determine despre ce câmp este vorba, apoi să analizeze șirul „42” și să îl convertească în 42 binar.

Prin urmare, penalizările de performanță pentru utilizarea XML sunt uriașe. Avantajele XML sunt faptul că este oarecum lizibil pentru oameni și că permite transferul ușor de date între sisteme complet separate. Niciunul dintre aceste avantaje nu se aplică pentru o bază de date locală.

Singura excepție o reprezintă fișierele de configurare, care sunt în general de dimensiuni mici și care, în general, trebuie să fie editabile de către oameni.

O bază de date XML va fi în mod absolut mai mare și mai lentă decât orice sistem SQL rezonabil. Cu excepția cazului în care puteți găsi un avantaj compensator în ceea ce privește lizibilitatea sau interoperabilitatea pentru oameni, nu are niciun rost să o utilizați pentru stocarea datelor.

Comentarii

  • Punctul critic aici este dimensiunea fișierului. Pentru static date statice cu o dimensiune mai mică de un megapixel, performanța de încărcare a unui fișier XML o dată nu este atât de mare. Am lucrat la o aplicație în urmă cu aproximativ 5 ani și am constatat că costul de încărcare a unui astfel de fișier era de ordinul zecilor de ms. Îndrăznesc să spun că calculatoarele sunt puțin mai rapide acum. –  > Por dave.
  • @dave: dar odată ce ai ajuns în zona aceea de mărime, formatul XML pierde semnificativ în departamentul „editabil de către om”. –  > Por Joachim Sauer.
  • Pentru a evidenția și mai mult problema, stocarea valorii „1000000000” ar fi tot 4 octeți într-o bază de date reală, în timp ce în XML ar fi 27 de octeți. –  > Por Daniel B.
Ryan Ternier

XML Este viabil în funcție de context. Dacă datele dumneavoastră sunt destul de statice și nu se schimbă prea mult (de exemplu, date de eșantionare), da, XML este o utilizare bună.

Setările de configurare, datele de eșantionare (chiar dacă sunt milioane de rânduri, dar se schimbă foarte rar), toate sunt utilizări bune ale XML.

Citirile/scrierile pe hard disk sunt costisitoare, mult mai mult decât accesarea datelor dintr-o stivă Oracle/Sql.

mortal

Acest lucru pare să sublinieze cu adevărat faptul că XML nu ar trebui să fie utilizat pentru stocarea datelor și ar trebui să fie utilizat doar pentru interoperabilitatea între programe.

Premisa dumneavoastră este greșită.

Paragraful pe care îl citați spune, de fapt, că XML nu este un înlocuitor pentru o bază de date, și nu că nu ar trebui să fie utilizat pentru stocarea datelor.

Este clar că un fișier de setări nu este același lucru cu o bază de date și, prin urmare, se pot (și ar trebui?) utiliza tehnologii diferite.

Corectați-mă dacă greșesc, dar se pare că aveți mai multă experiență cu limbajele de marcare decât cu bazele de date. Dacă ați avea puțină experiență cu bazele de date, v-ați da seama pentru ce domenii sunt potrivite cele două tehnologii diferite.

Kyle Trauberman

Acest lucru este cu adevărat subiectiv. Citatul ăsta e ca și cum ar fi opinia cuiva, omule.

Sincer, cred că XML este o alternativă viabilă la o bază de date, deoarece are mai multe avantaje față de un RDMS, inclusiv un nivel scăzut de cheltuieli generale, ceea ce echivalează cu o stocare mai ieftină (în special atunci când se utilizează un serviciu de găzduire care taxează separat bazele de date).

Aruncați o privire la dasBlog și BlogEngine. Ambele aplicații utilizează în mod implicit xml pentru stocare.

Acestea fiind spuse. Nu este un RDMS, iar dacă aveți o volatilitate ridicată (multe actualizări, inserări sau ștergeri) în datele dvs. sau aveți nevoie de o disponibilitate ridicată, utilizați o bază de date. XML este bun pentru stocarea unor lucruri mici, cum ar fi datele de configurare și datele cu volatilitate redusă.

Comentarii

  • Citatul este de fapt dintr-o carte. Ar trebui să adaug că în –  > Por Kian.
  • „O supraîncărcare redusă?” Cred că vrei să spui „nu necesită instalare”. Accesarea datelor dintr-un fișier XML mare are un timp imens, I/O și costuri de procesare. Da, XML este bun pentru lucruri mici (< 1MB), dar nu, XML nu este bun pentru date cu volatilitate redusă în general, ci doar pentru lucruri mici în general. –  > Por GlenPeterson.
  • Frumos omagiu Big Lebowski! –  > Por InvisiblePanda.
NoChance

întrebarea mea este: Este aceasta încă o declarație valabilă și este acum acceptabil să stocați date folosind XML?

Vă înțeleg punctul de vedere în exemplul dvs. despre fișierele de configurare .NET. Cu toate acestea, ar fi putut fi folosit orice alt format de fișier. De fapt, în vremurile vechi, astfel de setări erau stocate în fișiere text obișnuite, numite fișiere INI.

Văd că afirmația pe care ați prezentat-o în gri, este valabilă și corectă dacă definiți o bază de date ca fiind un sistem software.

Definiția XML din XML-Definitionafirmă că „(XML) este un limbaj de marcare care definește un set de reguli pentru codificarea documentelor într-un format care este atât lizibil pentru oameni, cât și pentru mașini.”

Această definiție se concentrează mai degrabă pe lizibilitate și limbaj decât pe mecanismele de gestionare a datelor.

În comparație cu un RDBMS, XML nu oferă mijloace de a introduce și șterge la întâmplare rânduri într-un fișier XML. De exemplu, dacă aveți 1000000 de rânduri și doriți să ștergeți rânduri la întâmplare, chiar și într-un mediu cu un singur utilizator, fișierul bazat pe XML nu ar fi o alegere bună pentru o bază de date. De asemenea, XML nu oferă niciun mecanism nativ pentru blocarea datelor. De fapt, deoarece XML nu este un software, toate proprietățile ACID (atomicitate, consistență, izolare, durabilitate) care garantează că tranzacțiile din bazele de date sunt procesate în mod fiabil într-un mediu partajat sunt lăsate la latitudinea dezvoltatorului (cu excepția durabilității). XML nu are o specificație robustă pentru a gestiona integritatea datelor între fișiere XML, cu atât mai puțin între servere diferite (de exemplu, fișierul xml al clientului și fișierul xml al comenzilor – nu există FK care să impună integritatea).

Cele de mai sus nu reprezintă o enumerare a lipsurilor din XML, ci ar putea servi ca o justificare rapidă a afirmației că XML nu este o bază de date. software.

Yusubov

XML nu a fost niciodată menit să fie o bază de date sau să o înlocuiască.

XML este definit în principal pentru documentele Web care allows for the creation of customized tags for individual information fields. Cu toate acestea, nu veți realiza niciodată cu el o gestionare centralizată relațională a datelor.

zxcdw

De ce ați dori de fapt să utilizați XML pentru stocarea datelor în primul rând? Adică, este un limbaj până la urmă…

Deși se poate spune că este un format flexibil și ușor de înțeles, acest lucru se aplică doar atunci când trebuie să editați manual fișierele. Atunci când interacționați efectiv cu baza de date cu o interfață comună (aduci datele X care îndeplinesc cerințele Y și Z, stochezi/actualizezi datele X, …) aceste avantaje devin nule.

Comentarii

  • Limbajele naturale au fost utilizate pentru stocarea datelor timp de secole. Înțelegerea se aplică și în cazul în care aplicația care o citește devine inutilizabilă (de exemplu, o aplicație pe 16 biți care nu a fost actualizată niciodată). Stocarea datelor într-un format ușor de citit de către om facilitează portarea; în special dacă formatul nu a fost niciodată documentat foarte bine sau dacă documentația s-a pierdut. –  > Por Paul Butcher.
  • Folosirea limbajului natural pentru a stoca date nu este în sine problematică, dar stocarea datelor într-un format care oferă o lizibilitate, o eficiență a informațiilor și un raport informații/conținut oribil (în comparație cu ceea ce ar putea fi) este ceva împotriva căruia m-aș pronunța personal. –  > Por zxcdw.
Simon

Răspuns scurt: Depinde.

Răspuns lung: Din punctul meu de vedere, acest lucru depinde foarte mult de cantitatea de date pe care doriți să o stocați. De exemplu, dacă aveți câteva obiecte în aplicație în timpul execuției și doriți să le stocați după rularea instrumentului, un fișier XML este perfect în regulă. Cu toate acestea, dacă magazinul dvs. web are 5 000 de clienți și chiar mai multe comenzi, o bază de date ar fi o modalitate mai potrivită de stocare a datelor.

În plus, cred că stocarea setărilor într-o bază de date și nu într-un fișier precum app.config nu este în majoritatea cazurilor foarte utilă, dar nu cred că acest exemplu dovedește că citatul este greșit.

Traxxus

XML este o alegere excelentă pentru setările de configurare. Fișierele XML nu numai că sunt ușor de analizat/subliniat într-un IDE, dar sunt foarte ușor de editat de către neprogramatori. Le găsesc incredibil de utile în scenariile de dezvoltare web în care sarcinile de întreținere sunt efectuate de designeri și manageri de conținut.

În mod normal, XML nu ar trebui să fie utilizat ca sursă principală de date pentru orice aplicații care nu sunt triviale. Numai costurile de serializare/deseerializare necesită o soluție diferită.

Daniel B

Termenul bază de date se poate referi fie numai la datele brute, fie și la sistemul de gestionare a bazei de date. Această definiție face o mare diferență în întreaga argumentație.

Dacă folosim definiția RDBMS, atunci XML are foarte puțin în acest sens. Obțineți foarte puțin în ceea ce privește garanțiile ACID (ar trebui să vă scrieți propriul cod pentru a le realiza). Dacă aveți nevoie de acestea (și majoritatea sistemelor tranzacționale au nevoie), aveți deja probleme majore. Aș putea da o listă de sute de caracteristici care sunt considerate de la sine în cazul SGBD-urilor, pe care ar trebui să le reinventezi și să le reimplementezi. Gândiți-vă la modelele de securitate, replicare, copii de rezervă, doar pentru a numi doar câteva dintre cele de bază.

În sensul de mai sus, nu, XML nu este o bază de date și nu ar trebui să încercați să o utilizați ca atare.

Dacă folosim definiția „date brute”, XML se descurcă mult mai bine, dar tot nu este atât de bine. După cum au subliniat și alții, este extrem de verbos în general, de obicei nu are codificare binară, are etichete duplicate etc. Acestea sunt compromisuri făcute pentru ca XML să poată fi lizibil pentru oameni – practic, eficiența este inamicul acestei cerințe. De asemenea, XML nu se potrivește în mod deosebit nici măcar în cele mai simple situații în care se introduc înregistrări în mod continuu. Presupunând că doriți ca fișierul XML să fie valid, aveți nevoie de o singură etichetă de închidere, ceea ce înseamnă că adăugarea unei înregistrări înseamnă că trebuie să decalați etichetele de la sfârșit. Acest lucru este destul de costisitor (de unde știm unde începe acea etichetă? dacă există mai multe „tabele”, pur și simplu mutăm în sus întregul fișier?), iar dacă doriți să ocoliți acest lucru, veți reinventa o abordare similară cu cea a multor baze de date – repartizarea tabelelor pe mai multe fișiere și creșterea dinamică a acestor fișiere în funcție de necesități.

Există situații în care XML este adecvat – fișierele de configurare sunt un exemplu excelent, deoarece sunt de obicei mici și lizibilitatea umană este o caracteristică excelentă de care trebuie să dispui. A avea o bază de date doar pentru un fișier de configurare poate fi exagerat.

Bazele de date, pe de altă parte, sunt excelente atunci când aveți mii (sau milioane/miliarde) de înregistrări și mulți utilizatori le actualizează simultan. Așadar, da, XML nu este o bază de date și nu ar trebui să o folosiți ca atare. Exemplul tău este una dintre acele situații în care nu aveai nevoie de o bază de date, iar XML este mai potrivit.

Eu văd lucrurile în felul următor: dacă folosești XML ca o bază de date (de exemplu, ca o memorie de rezervă pentru un sistem tranzacțional), vei ajunge să reinventezi și să rescrii un RDBMS.. Aceasta este o modalitate foarte proastă de a vă petrece timpul și energia. Cred că asta spunea și acel citat.

Shoey

Sunt de acord că nu este o bază de date relațională. Cred că autorul spune pur și simplu în citat să nu o folosești ca atare.

Acestea fiind spuse, totuși, s-ar putea să aveți sau nu nevoie de una. Dacă nu aveți nevoie să faceți prea multe interogări asupra datelor și intenționați doar să le stocați și să le recuperați mai târziu pe baza unor criterii de interogare limitate, atunci aveți nevoie de stocarea și recuperarea DOCUMENTELOR XML, nu de o bază de date relațională.

Există o mulțime de aplicații care au nevoie pur și simplu să stocheze un document cu date în el pentru a fi recuperat ulterior în întregime. În acest caz, este inutil să creați o schemă bazată pe SQL, să analizați XML-ul și apoi să îl serializați în baza de date pentru a face ulterior exact invers. Acest lucru ar putea implica o mare cantitate de cod. Totuși, este mai puțin dacă o faceți corect.

Puteți utiliza instrumente ORM precum Hibernate și instrumente precum Apache Axis pentru a genera automat practic tot codul de care ați avea nevoie pentru a crea un serviciu care să gestioneze doar operațiunile simple ale CRU. Desigur, va trebui să includeți autentificarea și, eventual, să separați datele în funcție de utilizator, de nivelul de acces etc. Este posibil să doriți chiar să limitați operațiunile pe care un anumit utilizator are voie să le efectueze prin intermediul serviciului SOAP, de exemplu.

În acest sens, faceți mai degrabă o gestionare a conținutului decât orice altceva.