Decizii, decizii
Un provocări cu greu în măsură atunci când aleg o tehnologie - este formarea unei imagini echidistantă a tuturor punctelor forte și punctele slabe ale produsului selectat. Acest lucru va confirma oricine care încearcă să ajungă la un fapt tehnic, au împotmolit în „splendoarea lucioasă“, „white papers.“
De aceea, comunitatea avansate de utilizator, ca, de exemplu, XML-DEV, au un avantaj imens în acest sens: ele oferă un loc pentru discuții și compararea obiectivă a meritelor diferitelor tehnologii. Apoi, înarmat cu faptele, și cunoscând toate „pro și contra“, un dezvoltator puternic va fi în măsură să ia o decizie mai informată. Procesul de luare a deciziilor poate fi îmbunătățită - în cazul în care ceilalți membri ai comunității doresc să împărtășească concluziile lor cu alții.
Deci, Brian Magic (Brian Magick), cu care se confruntă cu necesitatea de a alege o tehnologie bază de date adecvată pentru XML-cerere, adresată comunității XML-DEV cu o întrebare: Are cineva încearcă să nu se adune corespunzătoare „decizie copac“ ( „arbore de decizie“). Mai târziu, el a elaborat pe sarcina lui.
„Am vrut doar să înțeleagă principiul, atunci când trecerea la XML și de a crea aplicații cu baze de date, iar atunci când - nu se mișcă, și stochează datele în baze de date relaționale De ce unii preferă să păstreze datele într-un format relațională, mai degrabă decât a le converti în XML și să dezvolte XML. de bază. în ceea ce privește noile aplicații pe care dezvoltatorul ar trebui să ia în considerare atunci când se face o decizie de a merge în mod tradițional, în loc să profite de noul „rece“ XML-tehnologie? din păcate, prin selectarea datelor de bază XML, mulți dezvoltatori vor dori să utilizeze acest nou instrument noe înseamnă, deși este, de fapt, nu este pentru toate noile baze de date / aplicații. "
Cu toate acestea, avem nevoie de tine pentru a avertiza despre ceva. În primul rând, aceste considerații aparțin comunității XML-DEV; probabil, există și altele care trebuie abordate, cum ar fi cadru funcțional sau fiscal, care pot afecta într-un fel alegerea ta. În al doilea rând, unele dintre recomandările se bazează pe starea actuală a pieței bazelor de date; așa cum se dezvoltă, poate și alte idei vor deveni mai importante, iar factorii actuali vor fi mai puțin relevante. În al treilea rând, în câmpul vizual nu a primit produse speciale. Nu toate sistemele de gestionare a bazei de date sunt aceleași, astfel încât, cu siguranță, pentru fiecare regulă vor avea excepție lor. La fel ca trandafirii pot dezvolta pe gunoi de grajd, și produse cu o bună reputație poate ascunde ceva, să zicem, dezgustător.
Alegerea unei baze de date
Cea mai mare parte a datelor
„Am văzut o descriere a tipului de document șablon cu sute de membri, precum și determinarea acceptabilă a le transforma într-o bază de date. - nu este, evident, o sarcină trivială, mai ales atunci când multe dintre elementele sunt învelișurile care nu reflectă structura reală a bazei de date“ (Ronald Bourret)
Cele mai multe documente
Dacă ceea ce stocarea, într-o mare măsură - documentele, și nu pentru cele mai multe cazuri datele. atunci NXD poate fi cea mai bună soluție. Cu toate acestea, acest lucru va depinde de tipul de interogare pe care trebuie să faceți pentru aceste date. Unele documente au scheme de metadate evidente. care simplifică relational mapping. Tocmai converti conținut amestecat într-o schemă relațională nu este ușor, și XML document este adesea schimba structura.
. „Conținutul mixt prost convertit prin maparea relațională-obiect. (Eu nu am de gând să intru în detalii. Mai multe detalii despre acest lucru este scris în secțiunea 3.3 și 3.4,“ Conversia unei descrieri șablon de document în baza de date „[DTD-uri de cartografiere la bazele de date]. (Ronald Bourret)
„Este mult mai ușor să se mențină un set de documente XML-folosind baza de date XML-decât pentru a transforma aceste documente într-o bază de date relațională, sau chiar să le păstrați ca“ (Tom Bradford (Tom Bradford)) pată de cerneală. "
structura de schimbare
Bazele de date relaționale sunt foarte bune pentru stocarea de informații foarte structurate și nu sunt bune pentru gestionarea datelor semi-structurate. document XML, de obicei, are o structură variabilă pentru flexibilitate contabile tipic prozei obișnuite. Cu toate acestea, nu toate datele sunt semi-structurate pe documente (de exemplu, liste de materiale). Deși informațiile semi-structurate pot fi convertite într-un model relațional, este posibil deasupra capului pentru performanță, mai ales atunci când rulează interogări. NXD sau XED cu posibilitatea de indexare XML-date sunt perfecte pentru acest tip de informații.
„Date semi-structurate - datele pe care au o anumită structură, dar nu sunt structurate în mod rigid exemplu de date semi-structurate este de a înregistra în exemplul medical, pentru un pacient, acesta poate conține o listă de vaccinări pentru o alta - .. Parametrii de înălțime și greutate, pentru a treia - operație pe care a suferit un alt exemplu de date semi-structurate. - documente juridice, înregistrări genealogice.
date semi-structurate este dificil de a stoca într-o bază de date relațională, ca și în acest caz, aveți o mulțime de diferite tabele (ceea ce înseamnă mai multe conexiuni și timpul de căutare lungă), sau un singur tabel, cu o mulțime de coloane goale. Semi-structurate de date stocate foarte ușor ca XML, si ele sunt perfect potrivite pentru XML-baze de date „(Ronald Bourret)
„Unul dintre principalele avantaje de model (date legate de date XML) este capacitatea de a gestiona date semi-structurate. In timp ce bazele de date relaționale nu pot fi date semi-structurate suficient de bine să se ocupe.“ (Dan Ueynreb (Dan Weinreb))
structura rigidă
Dacă stocați XML, schema care are o structură fixă (de exemplu, puțin sau deloc utilizarea de conținut mixt sau modele de conținut recursive), în timp ce baza de date relațională poate fi o soluție mai acceptabilă.
„Bazele de date relaționale sunt, în general, cel mai bun mod de a stoca date foarte structurat. Deși majoritatea XML-furnizori cu care am vorbit, spunând același lucru, nici unul dintre ei nu poate spune exact unde să tragem linie.“ (Ronald Bourret)
metadate evidente
De obicei, pentru a reprezenta structura header-corp (structura cap-corp), șablonul de proiect este utilizat în XML-scheme, metadatele incluse în antetul documentului și conținutul - în organism. În acest caz, este adesea necesar să se indice metadatele din antet și se referă la ele cu solicitarea. Acest model este destul de ușor să se transforme într-o bază de date relațională sau XED, deoarece, în special, metadatele folosesc rar conținut special mixt. Dacă schema (și) (i) se potrivesc acestui model, atunci această metodă de depozitare - soluția potrivită. Puteți folosi posibilitatea de a sprijini XML, dacă doriți să manipuleze conținutul corpului sau se referă la ea cu solicitarea. Cu toate acestea, în cazul în care aveți nevoie pentru a face interogări complexe la conținutul documentului, dacă este posibil, mai bine pentru a alege o baie XML de bază.
probleme complexe
Atunci când se analizează tehnologia bazelor de date este foarte important să se ia în considerare modul în care va fi accesarea datelor. Dacă vă concentrați pe datele XML. probabil SGBDR - cea mai bună alegere, precum și pentru XML-documente care au metadate evidente. Cu toate acestea, de îndată ce aveți nevoie pentru a efectua o căutare full-text sau manipula conținutul recursiv modelul sau NXD XED cu un cablu adecvat interogări limba XML par soluție mai acceptabilă.
Deși cel mai popular limbaj de interogare - considerată XPath (de obicei, cu extensii pentru interogări la mai multe documente), susținute de multe alte limbaje de interogare (toate specializările). Acest lucru este valabil atât în ceea ce privește bazele de date relaționale care suportă XML și XML de baze de date.
Ea are propriile sale motive - XPath suficient de dezvoltate pentru a îndeplini toate cererile care are nevoie utilizatorul, și XQuery nu este încă terminată. Am o suspiciune că, atunci când lucrările la XQuery sunt finalizate, vor fi multe înfăptuirilor sale. „(Ronald Bourret)
Spațiul de stocare distribuit
Foarte des se întâmplă că aveți pregătit depozit de date (care sunt realizate în investițiile corespunzătoare) ale cărei date pe care doriți să îl utilizați cu date XML-lor. În acest caz, va trebui să ia în considerare beneficiile integrării în cadrul întreprinderii, folosind NXD. În plus, pot exista probleme de integritate a datelor. În plus, posibilitatea de date utilizate în legătură cu aplicațiile care nu acceptă XML, se referă la cerințele de bază; acest lucru este adesea adevărat de date bazate pe XML, iar această situație se produce, de obicei, atunci când adăugați un ecran XML gata într-o bază de date sau depozit. Cu aceasta în minte, RDBMS sau XED - este alegerea perfectă.
„Pentru cea mai mare parte va fi limitată la o bază de date relațională, mai ales în cazul în care cele mai multe aplicații, primesc date de la ea, nu trebuie să manipuleze datele sau să le vizualizați ca XML. Într-o astfel de situație este destul de multe straturi middleware XML sau de conversie capabilități care sunt susținute de cele mai multe RDBMS“ . (Tom Bradford)
„Sunt date într-o bază de date relațională care acceptă XML, disponibile ca pentru XML, și nu aplicații bazate pe XML. - Asta, cu rare excepții, nu se poate spune despre XML-baza de date care este, aproape nici unul dintre aceste XML bază de date nu suportă date returnarea într-o altă țară decât XML în format“. (Ronald Bourret)
„O altă întrebare - dacă aplicațiile non-XML utilizează datele fără a cunoaște XML Da -. Dacă XML este convertit la o masă, și nu există nici - dacă XML este stocat într-o pată de cerneală“. (Ronald Bourret)
investiții curente
Ca și în orice evaluare a tehnologiei, trebuie să țină cont de capitalul curent; diminua inacceptabil investițiile în dezvoltarea anumitor caracteristici. baza de date XML nu este necesară pentru multe aplicații, tehnologia existentă poate oferi deja funcționalitatea necesară. XML-proprietăți vor fi incluse în baza de date la fel cum au fost adăugate proprietățile obiectelor. Sau chiar ia XED NXD poate fi la fel de simplu ca să rămână pe platforma actuală și de a începe să utilizeze noua funcționalitate, de îndată ce apare. Această abordare este acceptabilă în cazul, dacă adăugați suport XML la o aplicație existentă, cu scopul final de stocare partajat.
# 9496. „;“ Pentru ce persoanele care utilizează RDBMS pentru a stoca datele lor clasice cheie corporative trebuie să se mute în XML, ca model de date? În final, modelul relațional este foarte bine potrivit pentru nevoile lor. Nimeni nu a raportat încă pe criza provocată de dizabilitățile relaționale pentru a partaja. Mai mult, în astfel de sisteme, trecerea de la un model de date relațională la orice alta - o societate care va necesita o mulțime de efort. Pentru aceste baze de date a fost creat marea suprastructură: instrumente de raportare, rapoarte, scrise pentru aceste generatoare, toate tipurile de instrumente și extensii oferite de furnizori, faptul că o armată mare de oameni a fost adus în spiritul a treia formă normală, limbajul SQL, și așa mai departe și altele asemenea.
. Imaginați-vă cum XML-SGBD încearcă să împingă baze de date relaționale, încercați să obțineți peste ele și să le înlocuiască, și veți înțelege modul în care toate acestea nu este gravă. „(Dan Ueynreb)
Numeroase scheme sau chiar absența schemei
Dacă aveți nevoie pentru a păstra documentele referitoare la numeroase scheme sau în absența schemei (ceea ce înseamnă că va trebui să se ocupe de date semi-structurate), efortul necesar pentru a dezvolta relational mapping pentru anumite tipuri de documente (în special cele care vor satisface toate cerințele pentru cerere), poate fi prea mare. În cazul în care schemele sunt în continuă evoluție, mai ales dacă nu se poate controla, această problemă se va inrautati. În acest caz, NXD cu spațiu de depozitare flexibil - o alegere excelentă.
„În cazul unor surse multiple de date poate fi foarte benefic pentru a utiliza XML pentru a descrie date structurate. Dacă nu aveți control deplin“ schemă „sau o formă de informație care vine de la diferite servere. Utilizați XML baze de date, independent de sistemul va reduce timpul de dezvoltare și ușurința „povara“ a suportului pentru viitor: nu va trebui să creați și să transforme [numărul] de scheme relaționale pentru a reprezenta toate diferite surse sale, de asemenea, nu trebuie să sprijine acest sistem în cazul unor schimbări „.. (Lord Bob (Bob Lord))
crawl completă
Atunci când conversia XML document într-o bază de date relațională (sau chiar xat, dacă nu utilizați un BLOB pentru a stoca întregul document) este aproape inevitabil ca unele dintre informațiile de pe acest document vor fi pierdute. XML baza de date nu „păcat“ ea. Prin urmare, în cazul în care aveți nevoie ca datele păstrate structura lor inițială în timpul depozitării și extracție, NDX - o soluție unică. Un crawl complet este probabil să fie o cerință de bază în punerea în aplicare a integrării în cadrul întreprinderii. Este nevoie să se mențină înregistrarea jurnalele de mesaje schimbate între sisteme.
integritatea datelor
integritatea referențială este baza modelului relațional. Cu toate acestea, XML poziția de integritate nu este atât de bine definită; deși legătura între tehnologie și există de multe ori nu este clar modul în care cel mai bine să le folosească, și va necesita, probabil, cod cerere pentru a menține integritatea. Dacă este o cerință strictă, este mai bine să aleagă o bază de date relațională sau o bază de date care acceptă XML.
Integrarea în întreaga întreprindere
Cea mai comună metodă de aplicații XML, în special pe baza datelor. - este să-l folosească ca mijloc de integrare sau schimb de date între aplicațiile de întreprindere din interiorul sau din afara firewall-ului. De-a lungul ultimilor ani au văzut dezvoltarea de software middleware, precum și cu extinderea utilizării XML pentru aceste tipuri de mesaje, The NXD poate pretinde a fi un control al fluxului de mesaje. Acest lucru este valabil mai ales în cazul în care mesajul nu va fi utilizat imediat (și nu au nevoie să cache), acestea trebuie să se înregistreze pentru motive juridice, sau dacă acestea vor necesita un sprijin pentru tranzacții.
XML-baze de date par a fi o modalitate foarte bună de a integra date din diferite stivuitoare (backend), și cred că viitorul pentru baze de date XML - o vor face în mod transparent și reversibil. (Unii o fac azi.) În bazele de date relaționale în această chestiune poate fi dificultăți ca urmare a integrării datelor din diferite surse sunt susceptibile de a fi semi-structurate și nestructurate de date. „(Ronald Bourret)
„Sunt total de acord cu faptul că integrarea datelor din diferite stivuitoare - unul dintre punctele forte ale XML-baze de date, precum și capacitatea de a gestiona date semi-structurate - principalul lor avantaj.
Unele XML-SGBD este perfect potrivit pentru rolul memoriei cache tranzacțional permanente distribuite a stratului de mijloc. „(Dan Ueynreb)
„Fie că este o reprezentare fizică sau virtuală XML, integrarea datelor - unul dintre principalele motive pentru utilizarea XML, și furnizarea de funcționalitatea bazei de date pentru XML-reprezentare - unul dintre argumentele convingătoare în favoarea XML baze de date“. (Dzhonatan Roubi (Jonathan Robie)
„Ascundeți confuzia incredibilă care domnește în“ back office «pentru reprezentarea în cache în limbajul XML XML-baza de date, astfel încât alte aplicații nu știu sau nu-i pasa despre» samanism în spatele scenei. "
Fără îndoială, lista de mai sus se poate extinde și aduce alte argumente, care ar putea ajuta să se potrivească una cu alta considerație. Sper că acest lucru va fi un bun punct de plecare pentru discuții ulterioare.