[XML] database vs flatfile

[wibra]

de titel legt al heel wat uit.

ik moet mijn gebruikers opslaan "in xml". (project vraagt dat we die technologie gebruiken)

nu, waarom zou ik een native xml-database (zoals eXist) verkiezen boven een gewone xml-flatfile?

uiteindelijk zullen er 3 van die flatfiles/databases nodig zijn (user.xml, distribution.xml & service.xml)

mijn intuitie zegt dat een database robuuster is en gemakkelijker handelbaar is als je met grote hoeveelheden werkt. user.xml zou honderden tot evt enkele duizenden gebruikers bevatten (met name het gros van de wijnbouwers in zwitserland), distribution zou een 3-4-voud van die gegevens bevatten, zo ook voor service.xml

indien een xml-database te verkiezen is, hebben jullie ervaringen met eXist EN andere databases (zodat jullie een vergelijking kunnen opmaken)?

ter informatie: de verwerking gebeurt met java, voor zover ik de bomen door het bos zie zal dat SAX-objecten inhouden

[Janoz]

Ik zie eigenlijk geen enkele reden om data opslag in XML te doen (configuratie is weer iets anders natuurlijk). Zeker bij deze hoeveelheden gegevens is het compleet onzin om het op deze manier te doen. Waar komt die 'in xml' wens eigenlijk vandaan?

Imho hoor je XML te gebruiken bij het oversturen van gegevens. Dit soort dataopslag hoort gewoon in een normale database.


Trouwens, wat je daar 3 databases noemt, zijn in werkelijkheid 3 tabellen in 1 database.

[ Voor 12% gewijzigd door Janoz op 02-05-2005 11:58 ]

[wibra]

ik ben het volledig met je eens.

echter, dit is een project dat in een academische omgeving plaatsheeft, en mijn docent wil absoluut "gebruik maken van die technologie"

zelf vind ik het ook nogal dwaas, en ik heb hier mooi mijn MySQL-server al draaien, en daarmee werken lukt me perfect.

ik heb mijn docent veel van die beslissingen kunnen "afkouten" (vlaams voor "met succes afraden"). maar ze is het type dat als ze van een technologie heeft gehoord, ze het in dit project wil gebruikt zien. komt erop neer dat een vrij simpele applicatie enorm moeilijk wordt gemaakt door gebruik van allerlei overbodige en vertragende zaken.

[Verwijderd]

Je zou een flatfile XML testdatabase kunnen maken waar je random enkele duizenden records in zet.
Implementeer GEEN indexen of andere optimalisaties, laadt het niet in memory, en doe een paar zoek-queries en leg vervolgens je performanceproblemen bij je docent neer.
Laat ook zien dat MySql dit soort dingen in fracties van seconden kan.

Doe daarbij het voorstel om je applicatie een 'export' in XML te laten doen (daar is XML gewoon wel geschikt voor), en iedereen is blij, want dan zit er toch XML in.

[wibra]

dank!

lijkt me ook duidelijk dat een sql-database sneller is dan een xml-flatfile, maar hoe zit het met het verschil tussen een sql-database en een native xml-database? komt dat laatste gewoon neer op een ander soort queries(xquery), met verder (ongeveer) dezelfde performantie?

[Creepy]

Er zijn wat xml-databases op de markt, maar echt bruikbaar voor grote hoeveelheden data zijn ze niet. Waarom? Ze zijn (nog steeds) vele male trager dan een willekeurig RDBMS.

[wibra]

alright.

voorlopig ga ik maar voor de xml-flatfile. met een duizendtal gebruikers is die slechts een paar megabyte groot, als ik die pars met DOM en in het geheugen laad, hoogstens een tiental megabyte, wat vrij goed doenbaar is.

[MSalters]

Leg je docent maar uit dat "academische omgeving" geen excuus is voor stupiditeit. Juist daar tellen onderbouwde argumenten, en niet marketing euro's. Overigens is dat onder de aanname dat jij de zaak goed voorstelt; als je een "Export users" functionaliteit hebt, dan is XML wel een goede keuze.

[curry684]

MSalters schreef op maandag 02 mei 2005 @ 12:51:
Leg je docent maar uit dat "academische omgeving" geen excuus is voor stupiditeit. Juist daar tellen onderbouwde argumenten, en niet marketing euro's.

Dank dat je me de moeite van exact dezelfde opmerking bespaart

[NMe]

curry684 schreef op maandag 02 mei 2005 @ 13:18:


Dank dat je me de moeite van exact dezelfde opmerking bespaart

offtopic:
En mij. Weer iemand die XML als doel ziet i.p.v. als middel.

[wibra]

uiteraard hebben jullie gelijk.

maar langs de andere kant, dit geeft mij de kans om (onder lichte dwang) in contact te komen met deze technologie, wat uiteindelijk de bedoeling is (naast iets te hebben dat ook effectief werkt).

hier is het project dus niet het doel, maar een middel. en de gebruikte technologie is niet het middel, maar het doel.

om te commentarieren op MSalters: neen, de xml-bestanden of -database zijn/is enkel nodig als bron voor mijn applicatie, niet om verdeeld/ge-exporteerd te worden

[ Voor 19% gewijzigd door wibra op 02-05-2005 13:33 ]

[Alarmnummer]

Verwijderd schreef op maandag 02 mei 2005 @ 12:12:
Je zou een flatfile XML testdatabase kunnen maken waar je random enkele duizenden records in zet.
Implementeer GEEN indexen of andere optimalisaties, laadt het niet in memory, en doe een paar zoek-queries en leg vervolgens je performanceproblemen bij je docent neer.
Laat ook zien dat MySql dit soort dingen in fracties van seconden kan.

Doe daarbij het voorstel om je applicatie een 'export' in XML te laten doen (daar is XML gewoon wel geschikt voor), en iedereen is blij, want dan zit er toch XML in.

Het belangrijkste is dat een file systeem niet de ACID eigenschappen ondersteund.

[ Voor 4% gewijzigd door Alarmnummer op 02-05-2005 13:48 ]

[curry684]

wibra schreef op maandag 02 mei 2005 @ 13:31:
uiteraard hebben jullie gelijk.

maar langs de andere kant, dit geeft mij de kans om (onder lichte dwang) in contact te komen met deze technologie, wat uiteindelijk de bedoeling is (naast iets te hebben dat ook effectief werkt).

hier is het project dus niet het doel, maar een middel. en de gebruikte technologie is niet het middel, maar het doel.

Oftewel ze leren je aan om mooie technologie op de foutst mogelijke manier te gebruiken... wat is dan het nut van het project? * curry684 stelt voor dat je de URL van dit topic even naar de docent doormailt, er zijn hier genoeg mensen die die discussie graag aan gaan, leert hij er ook wat van

Alarmnummer schreef op maandag 02 mei 2005 @ 13:47:
[...]

Het belangrijkste is dat een file systeem niet de ACID eigenschappen ondersteund.

MySQL komt ook maar tot 1 v/d 4 geloof ik

[ Voor 15% gewijzigd door curry684 op 02-05-2005 13:51 ]

[Alarmnummer]

curry684 schreef op maandag 02 mei 2005 @ 13:50:
MySQL komt ook maar tot 1 v/d 4 geloof ik

[flame]
Maar MySql beschouw ik ook niet als een serieuze db. Het is meer een hobbybob db.

[edit]
MySql kan vast wel goed ingezet worden. Maar voor oplossingen waar data echt op een veilige manier opgeslagen moet worden (ACID eigenschappen verplicht) kijk ik toch liever naar iets zoals MsSql.

[ Voor 39% gewijzigd door Alarmnummer op 02-05-2005 13:54 ]

[wibra]

curry684 schreef op maandag 02 mei 2005 @ 13:50:
* curry684 stelt voor dat je de URL van dit topic even naar de docent doormailt, er zijn hier genoeg mensen die die discussie graag aan gaan, leert hij er ook wat van

neen danku. over zes weken moet die mij punten geven . ik hoop gewoon dat ik haar wat tevreden kan stellen ondanks haar eisen.

_{trouwens, ze kent geen nederlands. enkel frans, duits en ik vermoed italiaans. ik zit hier in zwitserland in het franstalig gebied en dicht tegen de italiaanse grens}

[curry684]

Alarmnummer schreef op maandag 02 mei 2005 @ 13:52:
[...]

[flame]
Maar MySql beschouw ik ook niet als een serieuze db. Het is meer een hobbybob db.

Of met de legendarische woorden van ele: "MySQL is a sorry excuse for a flat filesystem with indexes". Ja, MySQL is verdomd goed in te zetten, voor websites en fora is het de oplossing. Zodra het enigszins vitale data is kijk je echter zsm naar een database die wel bewezen is om de integriteit van z'n data te bewaken, en die niet 'by spec' random results op group by kan retourneren of 31-2-2005 of 'Pietje Puk' als geldige DateTime input beschouwt