moraš dati više detalja o implementaciji.. npr, da li app treba da bude client-server ili desktop, u kojoj tehnologiji nameravaš da je radiš (GUI ili web app), itd..

ok, sorry

trebalo bi da bude gui, iskljucivo desktop aplikacija.

u tom slučaju, osim ako količina podataka ne prelazi neku baš veliku cifru, jedan xml fajl će ti biti verovatno najelegantnije rešenje (ako prelazi, onda bolje da to ispodeliš na par xml fajlova).

prednosti u odnosu na sql server su što ti je od deploya dovoljan JVM da bi ti app radio, a i moguće lakša manipulacija podacima. još ako nađeš neki xml2java code generator (ne znam stručan naziv za ovo), ima da ti bude pesma da radiš ;)

Znaci da mi treba po jedan xml fajl da zameni svaku potencijalnu tabelu u bazi ?
Ili samo jedan fajl, pa da idem sa <tabela1> ... </tabela><tabela2>... ?

Kakav xml2code generator?

Ne znam kakve biblioteke imaš za javu, ali znam da na xml.apache.org ima puno softvera za xml (sve u javi). Čini mi se da bi ti bili neophodni neki DOM, XPath i/ili XQuery. Pogledaj na w3.org/TR/xpath20, w3.org/TR/xquery. Generalno sve možeš da uradiš i sa DOM-om, ali nema razloga da se maltretiraš ako već postoje xpath procesori (primer xpath-a je npr "//person[fname='John']", sto generalno ima slicnu funkcionalnost kao "select * from person where fname='John'" u SQLu).

Pozdrav
Filip

I sta vi cenite, moze li aplikacija tog tipa (desktop/GUI) lepo da radi na Celeronu450Mhz, cini mi se 98MB Ram-a ?

Moj savet je da tu aplikaciju ipak napišeš u C-u ili C++-u. Mislim da Java neće najbolje da se pokaže na takvoj mašini, mada ne mogu zasigurno da tvrdim :) Skini neku Java aplikaciju slične kompleksnosti pa probaj kako radi, pa ako bude ok, onda piši u Javi. A u suprotnom uzmi GTK i libXML i uživaj.

naravno da ne. iskoristi činjenicu da podatke u XMLu možeš da ugnježdavaš do proizvoljne dubine. zato recimo umesto dve tabele, Servisi i Delovi (zamenjeni u svakom servisu):



ti u XMLu imaš lepo stablo:



pošto u XMLu nemaš join kao u SQLu (a najčešće ti i ne treba).




ma mislio sam na one wizarde koji na osnovu DTDa ili šeme generišu c++/delphi/java/* kod koji se obmota oko samog DOMa za lakši pristup podacima. npr umesto domnode.childNode[7].Text pišeš job.person[7].Name ili slično.

ne znam kako se tačno ta opcija zove, ali valjda kapirate..


a, naravno da i ja preporučujem xpath. bez njega bi ceo posao bio prilično mukotrpan..


inače, na toj mašini će app raditi solidno, mada bih preporučio još koji Mb rama..

Znaci li to da xml-om mogu da potpuno izbegnem relacione tabele i sl., tj da sve podatke drzim na "gomili", po logici medjusobne pripadnosti tih podataka.

I kako je resen rad sa podacima u xml parserima (sortiranje, pretrage i sl.)?

Slicno mozes da postignes i sa LDAP bazom:)

Mada ne verujem da cu se upustati u tako nesto... ali hvala :)

pa otprilike znači to. za neke stvari (pretraga) ti posao završava xpath, a recimo sortiranje možeš i u javi lako da odradiš (pogledaj Comparable interfejs).

(a sa XSL može da se radi i sortiranje, ali se ne sećam da li je to deo xpath-a ili XSLa, i da li se/kako može iskoristiti u javi)

Evo linka ka stranici punoj informacija na ovu temu. Samo me kopka da li SDK moze isto to (posto je ovo za enterprise edition)...

http://www.j2eeolympus.com/J2EE/JavaXml/JavaXSL.jsp

Mozda je bolje da se drzis resenja koja su vec godinama proverena u praksi. Bilo koja ozbiljnija poslovna aplikacija mora da radi sa vise tabela (te je potrebno normalizovati potrebne relacije/tabele kako bi se izbegle anomalije pri manipulaciji podacima) a DBMS-ovi su dusu dali za te setuacije.
Sumnjam da upotrebom XML-a bilo sta dobijas (pogotovo ako se to razvije u klijent/server resenje).

Ovo se sigurno nece razviti u klijent/server aplikaciju. Inace, struktura podataka ide ovako:
Svaka musterija(korisnik) ima podatke (broj licne karte it.d.) koji su potrebni. Takodje, svaki od njih ima jedan ili vise automobila sa podacima tipa kubikaza, snaga motora, godina prizvodnje i sl.
Imaju podaci o kucama koje rade osiguranje (razlicite tarife, sema popunjavanja obrazaca za svaku od njih), i podaci o ostvarenim ugovorima sa klijentima (mada se i za svaki auto moraju cuvati podaci o registraciji i osiguranju).
Znaci imam prilicno strukturiranu semu... zato je mozda dobro koristiti xml, jer bi islo

Nije dobro da sve strpaš u isti XML tag. Bolje je da neke stvari odvojiš. Na primer ovako:


Možda bi još trebalo da bude odvojenih "tabela", mada, po onome što si rekao, čini mi se da je ovo dovoljno. A selektovanje odgovarajućeg ID-a vršiš preko XPath-a, kao što sam napisao u prethodnom postu.

Pozdrav
Filip

Meni se čini da praviš grešku u startu. XML nije zamena za relacione baze podataka. Za ovako nešto bih ti savetovao da koristiš npr SQLite ili sličan "lagani" DB engine.

Ovo je samo moje licno misljenje: Ja ipak mislim da je najlaganiji
moguci DB engine bolji od bilo kakve "XML baze". XML-u nije mesto medju
bazama, zasto ga trpaju tamo gde mu nije mesto je opstepoznato...
Mozda sam konzervativan, ali ipak XML-u tu zaista nije mesto.

Znaci li to da u aplikaciji ovog tipa xml predstavlja lose resenje za skladistenje podataka?

Ja bih se vrlo složio sa Lekom a evo i zašto. XML je, kao što mu i ime
kaže, jezik za označavanje (markup language), pa prema tome služi samo
za opis neke (statičke) strukture. Dakle, kada imate bazu podataka,
njenu strukturu možete lako zapisati u XML kako biste je
transportovali između dve aplikacije i to je jedina dodirna tačka
XML-a sa bazama podataka. (Da ne kažem: jedini razlog što se XML dovodi
u vezu sa bazama podatake jeste što se u DBM dijalogu tamo negde pominje
skraćenica XML) Dovoljno je dobro standardizovan da ga možete proizvesti
na jednom mestu i očitati na drugom.

Korišćenje XML-a kao formata za podršku manipulaciji podacima u bazi
nema nikakvog smisla. Nije da nije moguće izvesti ali je jednako
nespretno kao korišćenje .txt fajla za pamćenje slogova. XML fajlovi su
ništa drugo nego običan tekst kome se bez posebnih akrobacija može
pristupati isključivo sekvencijalno. Da je OP pitao da li da koristi
..txt datoteku za pravljenje baze podataka verovatno bi mu svi rekli da
to nije dobro rešenje; ovako je XML ubacio zabunu tamo gde ne treba da
je bude.

Dakle: pravac neki DB engine.

f

Znaci xml-u nije mesto u razvoju poslovnih aplikacija i sl., gde se vrsi obilna manipulacija podacima. A zasto je onda u poslednje vreme toliki akcenat na njemu? I za sta ga vi konkretno koristite?

... razmena podataka između različitih aplikacija.

Magična reč je standard. Mnogim programima je u suštini potrebno
da pamte nekakve statičke strukturirane informacije. Seti se na primer
raznih inicijalizacionih datoteka (win.ini ili nešto slično). Kako nije
bilo opšteprihvaćenog standardnog zapisa, svako se snalazio kako je znao
i umeo. To znači da je manje-više, za svaki način zapisa morala da
postoji posebna biblioteka koja sa tim zapisom zna da radi, kao i da su
te biblioteke uglavnom među sobom bile nekompatibilne.

XML je formulisan dovoljno opšte da ima jasnu standardizovanu formu i da
može da zadovolji zahtev: ima strukturu i ta se struktura može opisivati
na dobro definisan, standardan način. Pojavile su se zatim dovoljno
dobre biblioteke za obradu XML-a i — ostalo je istorija.

f

Uz sve dužno poštovanje, ne bih se u potpunosti složio. Jeste da čovek u svakom slučaju treba uzeti neku laganu bazu, ali nije tačno to da XML-u nema mesta u manipulaciji podacima. Evo kako:

Problem sa klasičnim SQL upitima je što uvek vraćaju tabele, znači nešto kockasto, da se stručno izrazim. Kad ti treba neki složenija struktura, moraš da radiš 2-3 upita zaredom. XML je za razliku od tabele, nešto drvenasto per se, a po potrebi može da glumi i kocku (uh pardon pravougaonik).

Naime, XML se može koristiti za format rezultata koji vraća baza podataka (za upite sa relativno malom količinom podataka), a koji ne mora da bude kockast. Da se razumemo, ispod svega toga i dalje leži i prede motor brze relacione baze podataka sa sve direktnim pristupima, keširanjima, optimizacijom upita i ostalim čudesima modernog doba.

Druga stvar, jeste da se u krajnjoj liniji XML-u pristupa sekvencijalno ali je bitno reći da to vrlo retko radi programer, a mnogo češće neki XML parser, vrlo često i u vidu XSL transformacija. Poenta je da se programeri oslobode smaračina tipa parsiranje, ručna konverzija formata itd. Postoje čak varijante da između relacione baze i klijenta ne postoji aplikacija u tradicionalnom smislu: cela komunikacija u oba smera svodi se na XML.

Ko nije do sad, može da pogleda malo:

http://msdn.microsoft.com/sqlxml/
http://www.sqlxml.org/

Ne znam da li si primetio, OP je pitao da li može XML da koristi za
interni format u kom se čuvaju podaci.

f

I takvi XML-ovi se koriste samo za citanje a ne i za upis dodatnih podataka

Hmm. Pa ne znam bas:

http://www.topxml.com/sqlxml/updategrams.asp

Koliko sam shvatio iz teksta ciji si link dao ti umesto da posaljes "cistu" SQL naredbu saljes XML fajl koji sadrzi specijalno formatiranu SQL naredbu (sto znaci da i dalje moras da imas DBMS). Elem lepo je, sve to ali razlozi koji su izneti u prethodnim postovima su sasvim dovoljni za izbor DBMS u odnosu na XML kao tehnologije za interno cuvanje i obradu podataka.

Za takav tip aplikacije java kao razvojini alat nije bas pogodna, a nije joj cak ni namena. Problem koji treba da resis (poslovna aplikacija) mislim da neces bas najbolje resiti sa XML zato ti treba neka baza podataka.
Izbor alata i baze zavisi od mnogo vise parametara :

Generalno :
- okruzenje u kojem ce raditi alikacija ?
- da li treba aplikcija da bude portabilna na razlicite
operativne sisteme ?
- kolika treba da bude pouzdanos ?
- ...

Mrezna varijanta :
- da li ce raditi u mrezi ?
- ako ce raditi u mrezi, da li ce biti poseban database server ?
- koja je brzina mreze ?
- kakve su radne stanice i koji OS koriste ?
- ...

Single desktop :
- OS na masini
- brzina
-...
Ovo su pitanja koja postavi pre nego sto pocnem sa izradom bilo kakvoga programa.
Na osnovu odgovora se odlucijem na sta da koristim i na koji nacin da radim.

PS. Ima pitanja jos. Ova su mi bila trenutno u glavi :-)

Evo da ja probam da pojednostavim pricu:

Kad razvijas ovakvu aplikaciju koristi neku bazu podataka, a ako postoji i najmanja sansa da ce recimo aplikacija doziveti nekada web verziju i slicno onda odradi XML komunikaciju izmedju aplikacije i baze.

App. - xml - DB

Mislim da file based data storage nije dobro resenje.

Hvala!

Mislim da cu da osakatim neki linux pa na njemu da poteram mysql + XWindows + program o kojem se prica.
Sta si tacno mislio pod komunikacijom izmedju programa i baze xml-om:
da napisem klasu koja ce da radi komunikaciju sa bazom, a sa kojom ce program da "opsti" pomocu xml-a?
U cilju lakseg prelaska na drugu bazu?

Pravilno razmišljaš :)



Ma ne, ne treba ti da pravis klase za rad sa bazom pomoću XMLa. Ako to podržava baza ili ako već postoje klase koje to mogu da ti obezbede za više baza podataka, onda ok. Inače je možda najbolje rešenje da na praviš apstraktnu baznu klasu za rad sa bazom, pa onda da je naslediš u konkretnu implementaciju, kako bi olakšao prelazak (odn. da se prelazak svodi na pisanje novu nasleđenu klasu + zamenu DBklasa db = new KonkretnaDBklasa()). A najbolje je da nađeš na freshmeat/sourceforge neku već postojeću apstrakciju klasa za baze. Možda ti odgovara nešto kao http://dbstep.sourceforge.net/, pogledaj, imaš i primere online... A ima i izlaz u XML.

Pozdrav
F