[database]XML v.s. SQL(o.i.d.) in Flex

[Pkunk]

Hellew tweakers,

Voor een applicatie die ik wil gaan bouwen in Adobe Flex ben ik op zoek naar informatie over de voor en nadelen van XML t.o.v. databases zoals bijv SQL.
Volgens mij, maar daar kan ik dus geen cijfertjes over vinden, zijn databases een stuk sneller dan XML. Toch zie ik vaak genoeg website met databases die zijn opgebouwd uit XML bestanden. Ik gebruik het zelf ook veel. En volgens mij is het dus zo dat voor kleine sites XML uitermate geschikt is, maar als je echt grote hoeveelheden data wil opslaan kan je beter een SQL database gebruiken.
De applicatie waar het in dit geval om gaat zou een bedrijfsadministratie tool moeten worden voor een bedrijf met c.a. 100 medewerkers. Hier moet dan inzitten dingen als een uitgebreide uren administratie, facturatie, klantgegevens e.d.
Mijn eigen ervaring met XML is dat dit gewoon prima zou kunnen, alleen heb ik mij nooit al te veel zorgen hoeven te maken om de snelheid. Zolang het maar niet storend traag is zeg maar. Denk dan aan bestanden tot zo'n 15k aan regels.

Ook kom ik dit soort dingen tegen op internet:

An XML "file" is usually created from a database, cached and then available for smaller queries. You never would want to have a XML file that is too large because it will be a resource hog.

en

If you have a site of 100s or 1000s of pages in a heirachial structure and you store this in xml you will have major issues searching, sorting, paging, etc.

Waarom dan niet gewoon het zekere voor het onzekere nemen en gewoon SQL gebruiken? Omdat Flex goed met XML overweg kan kan ik meteen de XML aanspreken en hoef ik de database niet eerst om te zetten in XML. Daarnaast vind ik een XML database erg overzichtelijk en makkelijk werken.

Bottomline is dus deze zin:
"..volgens mij is het dus zo dat voor kleine sites XML uitermate geschikt is, maar als je echt grote hoeveelheden data wil opslaan kan je beter een database gebruiken"

Maar daar kan ik geen cijfertjes over vinden, en dus is het voor mij moeilijk te bepalen wanneer ik geen XML meer moet gebruiken.

[BtM909]

XML is niet bedoeld voor opslag, maar voor transport

[Pkunk]

BtM909 schreef op maandag 21 mei 2007 @ 10:30:
XML is niet bedoeld voor opslag, maar voor transport

Dat kan wel zo zijn, maar je kan het heel goed voor opslag gebruiken. Als je bestanden maar niet te groot worden. Maar hoe groot is dus mijn vraag. Ik heb zelf bijvoorbeeld een site met 500 (redelijk volle) pagina's volledig in XML staan. En dat gaat echt retesnel. Tel daarbij alle voordelen van XML bij op (compatible met zo'n beetje alles, makkelijk werken, etc..), en waarom zou je voor "databases" gaan?

[reddevil]

If you have a site of 100s or 1000s of pages in a heirachial structure and you store this in xml you will have major issues searching, sorting, paging, etc.

Je krijgt al problemen met zoeken en sorteren met kleine aantallen ook hoor. Een database kan ook veel meer, bijvoorbeeld complexe joins, group by's, counts, etc. XML is daar niet voor gemaakt.

Opslag --> database

[BtM909]

Overigens komt je topic beter tot z'n recht in Software Engineering & Architecture.

Ik verplaats hem dan ook voor je

[djluc]

Er zijn databases die zelf een XML export van een query kunnen doen zonder veel moeite. Misschien kan je daarmee wat doen zodat Flex het toch begrijpt en je dus "best of both worlds" hebt?

[whoami]

Timlog schreef op maandag 21 mei 2007 @ 10:38:
[...]

Dat kan wel zo zijn, maar je kan het heel goed voor opslag gebruiken. Als je bestanden maar niet te groot worden. Maar hoe groot is dus mijn vraag. Ik heb zelf bijvoorbeeld een site met 500 (redelijk volle) pagina's volledig in XML staan. En dat gaat echt retesnel. Tel daarbij alle voordelen van XML bij op (compatible met zo'n beetje alles, makkelijk werken, etc..), en waarom zou je voor "databases" gaan?

Hmm, referentiele integriteit ? Snel ff rapportage queries uitvoeren ? Met één query een set van records aanpassen ?
XML is echt niet geschikt voor dit doel; XML is geen vervanger voor een DB.

Ik heb een applicatie met daarachter een SQL Server DB (200 tabellen, 100.000den records). En dat gaat echt retesnel. Tel daarbij alle voordelen van SQL bij op (makkelijk werken, snel, integriteit, etc...), en waarom zou je voor XML gaan ? Ohja, die app gebruikt ook XML, maar dan om te communiceren met andere systemen.

[EfBe]

XML is geen database. Wil je dus database functionaliteit dan moet je een database gebruiken. XML wordt al over-used en een van de grootste blunders ever is wel het gebruik van XML als database. XML als format voor data van/naar services is gebruikelijk, maar voor lokale opslag zou ik nooit xml gebruiken, je kunt er dan geen reet meer mee.

[Pkunk]

Ik begrijp dat SQL een stuk beter is als je over grote hoeveelheden data gaat praten. En ook als je meer functionaliteit wil. Maar xml files zijn helderder en makkelijker deploybaar en backupbaar. Als ik het heb over kleine projecten zoals ik hierboven beschrijf zou het qua hoeveelheid data prima kunnen. Ik wil niet uit princiepe maar SQL gaan gebruiken omdat men roept dat XML nou eenmaal niet voor databases gemaakt is. Mijn ervaring is compleet anders. Het ligt er maar net aan waarvoor en hoe je het gebruikt.

Het is een project voor school, dus alles moet netjes gedocumenteerd worden. Daarom ben ik ook op zoek naar rapportages, verslagen, rapporten e.d.. waarin iets gedocumenteerd staat. Kennelijk nogal lastig te vinden, dus dan word het een beetje ervaringen uitwisselen.

Ik ben in ieder geval weer lekker aan het denken gezet. Er zijn wat voor en nadelen genoemd waar ik wat mee kan. Nu word het een kwestie van voor mezelf op een rij zetten wat de voor en nadelen zijn en kijken wat daar uit komt.

[whoami]

Niet mee eens; Een DB is makkelijk te backuppen, is makkelijk leesbaar (i.t.t. XML files) en deployment, tja... Hoe veel keer ga je een DB gaan deployen ? En wat met beveiliging ?

Maar goed, jij je zin enzo hoor ...

[jvbijleveld]

Daarbij; als er 2 mensen te gelijk een update op de XML doen krijgt er maar een voorrang, en verlies je dus informatie.
Een database kan meerdere 'connecties' aan,daar zul je dat probleem dus niet hebben.

ps: data - base (een 'base' met alle data )

[Pkunk]

whoami schreef op maandag 21 mei 2007 @ 11:49:
Niet mee eens; Een DB is makkelijk te backuppen, is makkelijk leesbaar (i.t.t. XML files) en deployment, tja... Hoe veel keer ga je een DB gaan deployen ? En wat met beveiliging ?

Maar goed, jij je zin enzo hoor ...

Dank voor het begrip

Zijn losse XML bestanden niet veel makkelijk te manipuleren dan een database? Je hebt het over losse bestanden die je met zo'n beetje alles kan openen. Dat lijkt me makkelijker dan een database waar je iets van een platform voor nodig heb om er iets mee te kunnen. Als jij mij nu een database geeft, wat kan ik daar dan mee als ik verder niets van SQL geinstalleerd heb?

Waarom is xml moeilijk leesbaar? Ik vind het juist hardstikke leesbaar. Misschien een kwestie van je XML goed structureren? Maar het zal wel kwesie van smaak zijn.

En wat met beveiliging?

jvbijleveld schreef op maandag 21 mei 2007 @ 12:03:
Daarbij; als er 2 mensen te gelijk een update op de XML doen krijgt er maar een voorrang, en verlies je dus informatie.
Een database kan meerdere 'connecties' aan,daar zul je dat probleem dus niet hebben.

ps: data - base (een 'base' met alle data )

true.. dus dat is een kwestie van bedenken hoe het cms in elkaar gaat steken. Je zou er omheen kunnen werken door een boom op te bouwen en die in je sessie stoppen. En pas als je klaar bent met editten die complete boom submitten. En dan kan je d.m.v. locken tijden saven zorgen dat er meerdere mensen tegelijkertijd kunnen editten. En dat werkt prima zolang er maar geen 20 mensen tegelijkertijd aan hetzelfde document werken.

[ Voor 29% gewijzigd door Pkunk op 21-05-2007 12:11 ]

[jvbijleveld]

Wat de beveiliging betreft; een XML bestand kan door elke boerel*l met een texteditor aangepast worden. (My)SQL heeft een degelijke rechten structuur waarbij je de hele boel kan afschermen zodat alleen een webclient met wachtwoord kan querien.

Maar ik lees net nog even terug dat het gaat om +/- 100 medewerkers. Dat kan je natuurlijk nooit redelijk laten performen vanuit een XML bestand. Bedenk dat elke keer als er een update wordt gedaan, de hele file opnieuw geschreven moet worden, en het risico dat er meerdere mensen tegelijkertijd aan werken is wel heel erg groot.

[Pkunk]

jvbijleveld schreef op maandag 21 mei 2007 @ 12:15:
Wat de beveiliging betreft; een XML bestand kan door elke boerel*l met een texteditor aangepast worden. (My)SQL heeft een degelijke rechten structuur waarbij je de hele boel kan afschermen zodat alleen een webclient met wachtwoord kan querien.

Dat ligt er natuurlijk aan hoe je je server inricht.

Maar ik lees net nog even terug dat het gaat om +/- 100 medewerkers. Dat kan je natuurlijk nooit redelijk laten performen vanuit een XML bestand. Bedenk dat elke keer als er een update wordt gedaan, de hele file opnieuw geschreven moet worden, en het risico dat er meerdere mensen tegelijkertijd aan werken is wel heel erg groot.

De vraag is dan ook of iedereen overal tegelijkertijd bij kan. Misschien zijn er maar 2 beheerders en kunnen alleen de officemanager bij de klanten en kunnen alle mederwerkers alleen bij hun eigen profiel. Dan zou het best werkbaar kunnen zijn. Maar da's dus nog een kwestie van even goed uitdenken.

[jvbijleveld]

Timlog schreef op maandag 21 mei 2007 @ 12:04:
[...]

... Je zou er omheen kunnen werken door een boom op te bouwen en die in je sessie stoppen. En pas als je klaar bent met editten die complete boom submitten. En dan kan je d.m.v. locken tijden saven zorgen dat er meerdere mensen tegelijkertijd kunnen editten. En dat werkt prima zolang er maar geen 20 mensen tegelijkertijd aan hetzelfde document werken.

En dan 'open' ik als eerste het XML bestand en update als laatste.....

Weg invoer van 15 andere collega's

[whoami]

Timlog schreef op maandag 21 mei 2007 @ 12:04:
[...]
Zijn losse XML bestanden niet veel makkelijk te manipuleren dan een database?

neen.

Als jij mij nu een database geeft, wat kan ik daar dan mee als ik verder niets van SQL geinstalleerd heb?

Waarom zou ik jou een database geven ? Als ik jou van bepaalde informatie wil voorzien die jij moet verwerken, dan lever ik ze wel aan in XML. Daarvoor is XML geschikt. Dan kan jij met die XML doen wat je wil. Inlezen in een DB (een ander DBMS, een andere structuur , whatever, mijn probleem niet, je doet er mee wat je wil).

Waarom is xml moeilijk leesbaar?

XML is makkelijk leesbaar voor software. Echter, het is een hel om het met het menselijk oog te bekijken. Hoe ga je een overzichtelijk kunnen zien welke orders een klant in de maand maart geplaatst heeft ?

Ik vind het juist hardstikke leesbaar. Misschien een kwestie van je XML goed structureren? Maar het zal wel kwesie van smaak zijn.

Ik geloof wel dat m'n XML goed gestructureerd is.

En wat met beveiliging?

Wat reeds gezegd werd.

[Pkunk]

jvbijleveld schreef op maandag 21 mei 2007 @ 12:19:
[...]
En dan 'open' ik als eerste het XML bestand en update als laatste.....

Weg invoer van 15 andere collega's

Je opent het pas als je gaat saven. Op het moment dat je gaat saven word het bestand gelocked en na het saven unlocked. Dat werkt prima. Je moet alleen niet op dezelfde plek iets editten.

[whoami]

Vind je nu zelf niet dat je al heel wat 'randvoorwaarden' opsomt waaraan moet voldaan worden om het geheel goed te laten werken ? 'Je moet alleen niet dit, je moet alleen niet dat, etc...'

Waarom zo zitten klooien en rond alles werken, terwijl een DB al die problemen voor jou afhandelt ?

[jvbijleveld]

true,

je hoeft het wiel niet opnieuw uit te vinden

[RobIII]

Als jij XML wil gebruiken ga dan vooral je gang We hebben het vaak genoeg gezegd: XML is niet de way to go. Als je dan toch doorgaat moet je ook leven met de consequenties:

• Geen referentiële integriteit _{tenzij je er zelf een laag omheen programmeert}
• Geen bulk-updates met statements als "Update foo set x = v where bar = y" _{tenzij je er zelf een laag omheen programmeert}
• Geen security _{tenzij je er zelf een laag omheen programmeert}
• Geen fatsoenlijke ordering, grouping, filtering _{tenzij je er zelf een laag omheen programmeert}
• Geen transactions / record locking etc. _{tenzij je er zelf een laag omheen programmeert}
• Geen... _{tenzij je er zelf een laag omheen programmeert}

Je zit dus gewoon het wiel opnieuw uit te vinden. Simple as that. Daarnaast is het uiteindelijke gebeuren geheid resource intensiever.

[ Voor 14% gewijzigd door RobIII op 21-05-2007 12:43 ]

[Pkunk]

whoami schreef op maandag 21 mei 2007 @ 12:23:
Waarom zou ik jou een database geven ? Als ik jou van bepaalde informatie wil voorzien die jij moet verwerken, dan lever ik ze wel aan in XML. Daarvoor is XML geschikt. Dan kan jij met die XML doen wat je wil. Inlezen in een DB (een ander DBMS, een andere structuur , whatever, mijn probleem niet, je doet er mee wat je wil).

Als ik met m'n klasgenootjes/collega's gezamelijk aan een database wil werken. De helft heeft namelijk geen SQL geinstalleerd op z'n pc en heeft daar ook geen zin in. Op die fiets bedoel ik het meer.

XML is makkelijk leesbaar voor software. Echter, het is een hel om het met het menselijk oog te bekijken. Hoe ga je een overzichtelijk kunnen zien welke orders een klant in de maand maart geplaatst heeft ?

Da's idd een goed punt. Ik stel me er zoiets bij voor. elke order heeft een id. dat id stop je weer bij elke klant. Je kan dan alleen niet in het xml bestand van de klanten zien welke datums bij die id's horen. Valt wel op te lossen met xpath, maar dan nog.

/edit:

whoami schreef op maandag 21 mei 2007 @ 12:33:
Vind je nu zelf niet dat je al heel wat 'randvoorwaarden' opsomt waaraan moet voldaan worden om het geheel goed te laten werken ? 'Je moet alleen niet dit, je moet alleen niet dat, etc...'

Waarom zo zitten klooien en rond alles werken, terwijl een DB al die problemen voor jou afhandelt ?

Nee dat is idd ook zo. Dus het zal ook wel een (SQL) database worden. Ik geef alleen maar aan dat het kan met XML. Het ligt er gewoon erg aan hoe je het gaat gebruiken.

[ Voor 20% gewijzigd door Pkunk op 21-05-2007 12:46 ]

[Brainstorm]

Er zijn genoeg problemen te verzinnen die je op zou moeten lossen als je met XML files werkt. Wat gebeurt er bijvoorbeeld als iets mis gaat (stroomuitval) terwijl je naar een file aan het schrijven bent? Wat als je in een transactie meerdere records wilt aanpassen (locking problemen, atomaire handelingen)?

Er zijn denk ik ook performance problemen: wat denk je dat efficiënter is als je 10000 records hebt en er 1 wilt veranderen: de file locken, lezen, 1 record veranderen en de file in het geheel weer terugschrijven, of 1 update query uitvoeren? Wat als je meerdere concurrent lezers hebt en 1 schrijver? Wat als je 1,000,000 records hebt, ga je die allemaal in het geheugen cachen (snel, maar resources nodig) of laat je dit op disk (langzaam qua toegang).

Tuurlijk, het is allemaal op te lossen.. maar een database doet dit al en waarschijnlijk beter dan dat je zelf kunt. De tijd die je kwijt bent aan het implementeren van je XML opslag kun je vervolgens weer ergens anders insteken.

Timlog schreef op maandag 21 mei 2007 @ 12:44:
[...]

Als ik met m'n klasgenootjes/collega's gezamelijk aan een database wil werken. De helft heeft namelijk geen SQL geinstalleerd op z'n pc en heeft daar ook geen zin in. Op die fiets bedoel ik het meer.

Maar ga je iets voor je klasgenootjes maken of iets voor een bedrijf, waar het eenmalig op een server geïnstalleerd wordt door een professioneel persoon?

[ Voor 19% gewijzigd door Brainstorm op 21-05-2007 12:48 ]

[RobIII]

Timlog schreef op maandag 21 mei 2007 @ 12:44:
[...]

Als ik met m'n klasgenootjes/collega's gezamelijk aan een database wil werken. De helft heeft namelijk geen SQL geinstalleerd op z'n pc en heeft daar ook geen zin in. Op die fiets bedoel ik het meer.

Dan moet "die helft" maar zien wat ze doen met jouw XML export die uit je RDBMS komt rollen Dan is het dus niet jouw pakkie an en kun je toch fijn gegevens delen. As said: XML is leuk om gegevens te delen met anderen maar niet bedoeld als "database".

[ Voor 8% gewijzigd door RobIII op 21-05-2007 12:47 ]

[EfBe]

Zwaar gevalletje Xml-itis hier

DE fout van XML is dat het Human-readable moet zijn. Dat is onzin. Het moet machine-readable zijn. De eigenschap dat het human-readable is (althans, als je je best doet) maakt het juist dat het te pas en te onpas wordt gebruikt, terwijl de enige reden dat XML bestaat is dat het gebruikt kan worden als universeel format voor data, en dan ook nog eens in een inmens inefficiente vorm.

[RobIII]

Timlog schreef op maandag 21 mei 2007 @ 12:44:
Nee dat is idd ook zo. Dus het zal ook wel een (SQL) database worden. Ik geef alleen maar aan dat het kan met XML. Het ligt er gewoon erg aan hoe je het gaat gebruiken.

Het kan ook met CSV files, binary files, ini-files, word-documenten, excel documenten en vele andere mogelijkheden. Je kunt ook een spijker in een plank rammen door er een sloopkogel op te laten vallen of door er flink op te meppen met een schroevendraaier. Je kunt ook gewoon een hamer gebruiken Dat is wat we hier (in essentie) zeggen

[ Voor 5% gewijzigd door RobIII op 21-05-2007 12:52 ]

[Pkunk]

RobIII schreef op maandag 21 mei 2007 @ 12:52:
[...]
Het kan ook met CSV files, binary files, ini-files, word-documenten, excel documenten en vele andere mogelijkheden. Je kunt ook een spijker in een plank rammen door er een sloopkogel op te laten vallen of door er flink op te meppen met een schroevendraaier. Je kunt ook gewoon een hamer gebruiken Dat is wat we hier (in essentie) zeggen

Agree, agree, maar pas aan het einde werd dat duidelijk Dat moet ik er toch wel even bij zeggen, voordat ik XML-itis naar m'n hoofd gesmeten krijg.. oh shit. te laat

[Johnny]

Timlog schreef op maandag 21 mei 2007 @ 12:44:
[...]

Als ik met m'n klasgenootjes/collega's gezamelijk aan een database wil werken. De helft heeft namelijk geen SQL geinstalleerd op z'n pc en heeft daar ook geen zin in. Op die fiets bedoel ik het meer.

De database draait toch op de server, en door verbinding te maken met die server kan je de database beheren, daar voor hoef je niks op de client te installeren, het kan ook gewoon via een web-interface, een remote desktop of door bijvoorbeeld PHP-bestanden bijvoorbeeld via FTP te uploaden. Ik krijg een beetje de indruk dat je niet echt begrijpt wat een echte relationele database precies is en wat de mogelijkheden er van zijn.

[Brainstorm]

Om trouwens terug te komen op je statement uit de eerste post: voor hele kleine statische sites is het misschien inderdaad wel beter om XML files te gebruiken. Niet zozeer vanuit het oogpunt van snelheid, maar meer dat het snel te bouwen is en weinig resources en onderhoud nodig heeft. Daarnaast is het inderdaad, wat je al zij, makkelijk te backuppen/verplaatsen (xcopy en je bent klaar).

Als je dynamische zaken wilt, is denk ik een database toch de juiste oplossing.

[Pkunk]

Johnny schreef op maandag 21 mei 2007 @ 12:57:
[...]
De database draait toch op de server, en door verbinding te maken met die server kan je de database beheren, daar voor hoef je niks op de client te installeren, het kan ook gewoon via een web-interface, een remote desktop of door bijvoorbeeld PHP-bestanden bijvoorbeeld via FTP te uploaden. Ik krijg een beetje de indruk dat je niet echt begrijpt wat een echte relationele database precies is en wat de mogelijkheden er van zijn.

En als je nou in de trein aan de database wil werken?

Ik begrijp wel wat een relationele database kan doen, maar ik heb nou eenmaal veel ervaring met xml/xsl en ik weet wat daarvan de mogelijkheden zijn. Op m'n werk werk ik met een framework waarbij je al die omwegen (meedere gebruikers, beveiliging) niet hebt. Dan is XML vaak gewoon veel handiger dan SQL. En dit is weer wat anders, wat nu heb ik dat framework dus niet, dus is het gewoon even afwegen wat er allemaal voor issues zijn die opgelost moeten worden wil je geen gebruik maken van SQL. En aangezien het maar om een klein project gaat zijn die redelijk te overzien. Maar uiteindelijk toch teveel, dus word het SQL.

[RobIII]

Timlog schreef op maandag 21 mei 2007 @ 13:07:
En als je nou in de trein aan de database wil werken?

Dan kun je nog altijd een export maken naar je geliefde XML en die later (aangepast dus) weer importeren in je DB En anders neem je een telefoon met UMTS ofzo Of je installeert een lokale versie van je RDBMS. Of ... beetje creatief denken

Timlog schreef op maandag 21 mei 2007 @ 13:07:
Ik begrijp wel wat een relationele database kan doen, maar ik heb nou eenmaal veel ervaring met xml/xsl en ik weet wat daarvan de mogelijkheden zijn.

Zo zal een timmerman een gebouw ook heel anders maken dan een staalwerker
Punt is dat, ook al is het voor jou makkelijker omdat je er zo in 'thuis bent', het niet altijd beter is.

[ Voor 8% gewijzigd door RobIII op 21-05-2007 13:13 ]

[Voutloos]

Timlog schreef op maandag 21 mei 2007 @ 13:07:
Op m'n werk werk ik met een framework waarbij je al die omwegen (meedere gebruikers, beveiliging) niet hebt. Dan is XML vaak gewoon veel handiger dan SQL.

Vraag maar eens hoeveel tijd in het bouwen van dat framework gestopt is. Dikke kans dat het niet binnen de deadline van je schoolopdracht past.

[JortK]

Ik ken een aantal mensen die hun applicaties eerst hebben opgebouwd met XML, maar hierna gauw naar een echt database platform zijn gegaan, puur omdat de functionaliteit van bijvoorbeeld queries en dat soort dingen veel uitgebreider is in SQL of een ander database platform als in XML.

[Janoz]

Timlog schreef op maandag 21 mei 2007 @ 13:07:
Op m'n werk werk ik met een framework waarbij je al die omwegen (meedere gebruikers, beveiliging) niet hebt.

Op je werk hebben ze dus een database nagebouwd .

Waarom blijf je databases trouwens stug SQL noemen? SQL staat voor Structured Query Language. Het is een taal. Het is dus enkel een standaard voor de manier van aanspreken van een database.

[Creepy]

Timlog schreef op maandag 21 mei 2007 @ 13:07:
[...]

En als je nou in de trein aan de database wil werken?

Je database ook op je laptop installeren

Op m'n werk werk ik met een framework waarbij je al die omwegen (meedere gebruikers, beveiliging) niet hebt.

Bedoel je dat meerdere gebruikers niet worden ondersteunt en er geen beveiliging is? Of hebben ze zelf een laag zelf gebouwd die een beetje DBMS zelf al heeft?

[djc]

RobIII schreef op maandag 21 mei 2007 @ 13:10:
Dan kun je nog altijd een export maken naar je geliefde XML en die later (aangepast dus) weer importeren in je DB En anders neem je een telefoon met UMTS ofzo Of je installeert een lokale versie van je RDBMS. Of ... beetje creatief denken

SQLite.

[Pkunk]

Creepy schreef op maandag 21 mei 2007 @ 14:25:
Bedoel je dat meerdere gebruikers niet worden ondersteunt en er geen beveiliging is? Of hebben ze zelf een laag zelf gebouwd die een beetje DBMS zelf al heeft?

De belangrijkste eigenschap van het framework is dat het werkt met XSL. Je kan daarin dus alles doen. En dat werkt echt super. Je kan bv apply-templaten op c# funties. En omdat xsl nou eenmaal makkelijk met XML werkt gebruiken we vaak XML.
Als jullie willen weten hoe het werkt kom je maar een keertje kijken

[Janoz]

Als jullie C# gebruiken, waarom gebruik je XML dan uberhaupt als dataopslag? Zelfs een accesskoppeling lijkt me nog handiger werken. Het enige verschil is dat je je resultaten nog ff naar xml moet omzetten voor je het opstuurt, maar dat lijkt me redelijk simpel. Zeker een stuk simpeler dan zelf uitgebreide locking en integriteits-checks implementeren (Mijn vermoeden is echter dat jullie dat helemaal niet geimplementeerd hebben).

Echt, het ziet er naar uit dat je hier uitgebreid aan het verkondigen bent wat voor mooie oplossing jullie hebben bedacht om met een schroevendraaier een spijker in een plank te slaan.

[Pkunk]

Janoz schreef op maandag 21 mei 2007 @ 16:08:
Als jullie C# gebruiken, waarom gebruik je XML dan uberhaupt als dataopslag? Zelfs een accesskoppeling lijkt me nog handiger werken. Het enige verschil is dat je je resultaten nog ff naar xml moet omzetten voor je het opstuurt, maar dat lijkt me redelijk simpel. Zeker een stuk simpeler dan zelf uitgebreide locking en integriteits-checks implementeren (Mijn vermoeden is echter dat jullie dat helemaal niet geimplementeerd hebben).

Echt, het ziet er naar uit dat je hier uitgebreid aan het verkondigen bent wat voor mooie oplossing jullie hebben bedacht om met een schroevendraaier een spijker in een plank te slaan.

Dit draadje ontspoort compleet. Ik heb geen zin om m'n werkt te gaan verdedigen. Geloof mij maar dat dat framework goed in elkaar zit. Als je anders vermoed is het jammer. Tis niet van mij, dus ik kan niet alles zomaar online gooien.

Mensen komen hier met beweringen dat dingen niet kunnen en dat XML maar dom is. Zo komt het over tenminste, terwijl ik om m´n werk dus duidelijk het tegenovergestelde ervaar. Er komen vervolgens allerlij voorbeelden waarin XML slecht is, waarop ik zegt dat dat op bepaalde manier opgelost kan worden (zonder te impliceren dat ik al heb gekozen voor XML, wat mensen er wel uit opmaken). Ik leg uit dat ik dat weet omdat ik werk met dat framework. Bovendien zijn veel van die oplossingen helemaal niet zo lastig. Vervolgens word ik in twijfel getrokken om iets waar het in eerste instantie helemaal niet om ging (namelijk dat zo'n framework uberhaupt mogelijk is..). Ik had beter niks kunnen zeggen kennelijk. Oorspronlijk was mijn vraag wat er voor een kleinschalig project handig was om te gebruiken. Dat bleek SQL te zijn. Klaar. Einde verhaal. Als je echt serieus geinteresseerd bent in het framework dat we gebruiken, stuur me maar een e-mail, dan stuur ik je het e-mail adres van de architect. Misschien nog wel leuk ook aangezien we zitten te twijfelen het open-source te maken.

[ Voor 4% gewijzigd door Pkunk op 21-05-2007 19:03 ]

[RobIII]

Timlog schreef op maandag 21 mei 2007 @ 19:02:
Mensen komen hier met beweringen dat dingen niet kunnen en dat XML maar dom is.

Bull. XML is geniaal (nou ja... ), maar dan wel als je het toepast waar het voor bedoeld is. XML is niet bedoeld om als database te worden mis/ge-bruikt:

quote: http://en.wikipedia.org/wiki/Xml

Its primary purpose is to facilitate the sharing of data across different information systems, particularly via the Internet.

Timlog schreef op maandag 21 mei 2007 @ 19:02:
Zo komt het over tenminste, terwijl ik om m'n werk dus duidelijk het tegenovergestelde ervaar.

Dat je positieve ervaringen ermee hebt wil niet zeggen dat het de way-to-go is en dat vertellen we je heel netjes; niet meer en niet minder. Er is niemand die je 'aanvalt' ofzo.

Timlog schreef op maandag 21 mei 2007 @ 19:02:
Er komen vervolgens allerlij voorbeelden waarin XML slecht is, waarop ik zegt dat dat op bepaalde manier opgelost kan worden (zodner te impliceren dat ik al heb gekozen voor XML, wat mensen er wel uit opmaken).

En wij vertellen je op onze beurt dat die oplossingen meer werk met zich mee brengen en daarnaast ook nog eens foutgevoeliger zijn. En dus in essentie dat je het (vierkante ) wiel opnieuw zit uit te vinden.

Timlog schreef op maandag 21 mei 2007 @ 19:02:
Ik leg uit dat ik dat weet omdat ik werk met dat framework. Bovendien zijn veel van die oplossingen helemaal niet zo lastig.

Niet zo lastig? Dan ben ik eens benieuwd hoe jullie een aantal van die punten 'simpel' opgelost hebben; om maar eens een graai te doen: referentiële integriteit, locking mechanismes, transacties, filters ("where... clauses").

Timlog schreef op maandag 21 mei 2007 @ 19:02:
Vervolgens word ik in twijfel getrokken om iets waar het in eerste instantie helemaal niet om ging (namelijk dat zo'n framework uberhaupt mogelijk is..).

Niemand beweert dat zo'n framework niet mogelijk is; hell: er zijn kant-en-klare databases die op XML gebaseerd zijn. We zeggen alleen dat je jezelf een hoop ellende en werk kunt besparen als je gewoon voor een database gaat en niet het wiel opnieuw gaat uitvinden.

Timlog schreef op maandag 21 mei 2007 @ 19:02:
Ik had beter niks kunnen zeggen kennelijk. Oorspronlijk was mijn vraag wat er voor een kleinschalig project handig was om te gebruiken. Dat bleek SQL te zijn.

Correctie: dat blijkt een Database te zijn; SQL is wat een database doorgaans 'spreekt'.

Timlog schreef op maandag 21 mei 2007 @ 19:02:
Klaar. Einde verhaal. Als je echt serieus geinteresseerd bent in het framework dat we gebruiken, stuur me maar een e-mail, dan stuur ik je het e-mail adres van de architect. Misschien nog wel leuk ook aangezien we zitten te twijfelen het open-source te maken.

You've got mail (Geintje )

[ Voor 6% gewijzigd door RobIII op 21-05-2007 19:22 ]

[Pkunk]

RobIII schreef op maandag 21 mei 2007 @ 19:08:
Bull. XML is geniaal (nou ja... ), maar dan wel als je het toepast waar het voor bedoeld is. XML is niet bedoeld om als database te worden mis/ge-bruikt:

Dat je positieve ervaringen ermee hebt wil niet zeggen dat het de way-to-go is en dat vertellen we je heel netjes; niet meer en niet minder. Er is niemand die je 'aanvalt' ofzo.

Nouja.. zo voelt het een beetje als uit het niets m'n werk in twijfel word getrokken. Er m'n werk is toch wel een beetje m'n trots, dus als iemand dan zonder er ook maar iets vanaf te weten gaat beweren dat we met een schroevendraaien een spijker in een plank proberen te slaan krijg ik toch wel redelijke "wat-lul-je-nou" nou gevoelens.

En wij vertellen je op onze beurt dat die oplossingen meer werk met zich mee brengen en daarnaast ook nog eens foutgevoeliger zijn. En dus in essentie dat je het (vierkante ) wiel opnieuw zit uit te vinden.

En dus zeg ik op een gegeven moment ook dat ik voor een mySQL database kies.

Niet zo lastig? Dan ben ik eens benieuwd hoe jullie een aantal van die punten 'simpel' opgelost hebben; om maar eens een graai te doen: referentiële integriteit, locking mechanismes, transacties, filters ("where... clauses").

Niemand beweert dat zo'n framework niet mogelijk is; hell: er zijn kant-en-klare databases die op XML gebaseerd zijn. We zeggen alleen dat je jezelf een hoop ellende en werk kunt besparen als je gewoon voor een database gaat en niet het wiel opnieuw gaat uitvinden.

Ja daar was ik dus ook al achter zoals ik ook allang gezegd had. Maar om toch even te benadrukken waar ik precies vandaan kom met m'n ideeën leg ik uit wat m'n achtergrond is. Vervolgens word die om no reason whatsoever (op een manier die insinueert dat ik bij een stelletje incompetenten werk) in twijfel getrokken.

Correctie: dat blijkt een Database te zijn; SQL is wat een database doorgaans 'spreekt'.

Jaja.. es-ku-el/siekwel.. laten we het er maar op houden dat ik syntax-dislectisch ben * Pkunk krijgt javaScript/Java gevoelens...

You've got mail (Geintje )

offtopic:
stiekem wil je het wel weten

Affijn, allemaal even goede vrienden, het was toch reuze interessant allemaal

[Janoz]

Timlog schreef op maandag 21 mei 2007 @ 20:02:
Nouja.. zo voelt het een beetje als uit het niets m'n werk in twijfel word getrokken. Er m'n werk is toch wel een beetje m'n trots, dus als iemand dan zonder er ook maar iets vanaf te weten gaat beweren dat we met een schroevendraaien een spijker in een plank proberen te slaan krijg ik toch wel redelijke "wat-lul-je-nou" nou gevoelens.

Uiteraard is er niks mis met het trots zijn op je eigen product of achievements. Trots is echter een erg zwak en vertroebelend argument in technische discussies. In technische discussies gaat het over argumenten, niet over trots. De enige reden waarom ik de schroevendraaier metafoor uit de kast trek is omdat je op eerdere opmerkingen over het verschil tussen een communicatie formaat aan de ene kant en een data opslag applicatie aan de andere kant niet reageerde.


Trouwens, als je de wiki pagina over xml databases daadwerkelijk leest zie je dat het ook daar vooral gaat over het communicatie formaat. De definitie daar van een xml database is dat de in en uitvoer in xml is. Er is een speciale subcategory gemaakt (native xml) doe ook in xml opslaat, maar verderop staat dat in de meeste gevallen deze cateogrie ook niet echt in xml opslaat.

[ Voor 31% gewijzigd door Janoz op 22-05-2007 10:02 ]

[MSalters]

EfBe schreef op maandag 21 mei 2007 @ 12:46:
Zwaar gevalletje Xml-itis hier

DE fout van XML is dat het Human-readable moet zijn. Dat is onzin. Het moet machine-readable zijn.

Welnee. Als je machine-readable wil, dan pak je ASN.1 of zoiets. XML is uitgevonden omdat er nog geen fatsoenlijk human-readable alternatief was voor ASN.1.

[Verwijderd]

jij kan geen papers vinden over xml databases ?

vreemd, ik zoek naar 'xml databases pro cons' en vind als eerste:

http://www.rpbourret.com/xml/XMLDBLinks.htm

veel plezier met lezen

[RobIII]

Verwijderd schreef op woensdag 23 mei 2007 @ 19:22:
veel plezier met lezen

Met alle respect, maar als ik zoek naar de "cons" op die page kom ik de volgende tegen:

1:

quote: http://www.rpbourret.com/xml/XMLDBLinks.htm

Native XML databases: a bad idea for data? by Kevin Williams. A brief discussion about why structured data fits best in relational databases. The subtitle "Taking a look at the pros and cons of native XML databases" is entirely misleading.

Lijkt me niet echt handig en daarbij is die link (naar de IBM site) zo dood als een pier.

2:

quote: http://www.rpbourret.com/xml/XMLDBLinks.htm

Medlane/XMLMARC Update: From MARC to XML Database by Kevin Clarke. A discussion about storing MARC (bibliographic) records as XML in a variety of databases. Interesting discussion of the pros and cons of various systems.

Ook niet echt relevant en daarnaast is de link (ook) dood...

3:

quote: http://www.rpbourret.com/xml/XMLDBLinks.htm

Going Native: XML Databases by Timothy Dyck. A commercial review of eXcelon, Ipedo, NeoCore, and Tamino, discussing the features, pros, cons, and cost of each.

Bespreekt dus commerciele XML Databases (in een, IMHO, totaal waardeloos review)...

En verder weinig cons op die page en (voor zover ik zo snel zie) weinig relevante informatie omtrend dit topic

Dat verandert overigens mijn standpunt (wiel opnieuw uitvinden, XML (mis)bruiken als "database") niet.

[ Voor 17% gewijzigd door RobIII op 23-05-2007 19:42 ]

[Verwijderd]

Mijn standpunt ook ZEKER niet. zoals al gezegd is xml een prima formaat voor het transporteren van gegevens en niet voor het opslaan.
met mijn post doelde ik eigenlijk meer op of de topicstarter wel 'goed' gezocht heeft (aangezien ik na een paar zoek queries wel degelijk veel info krijg over xml databases e.d.)
Ik ben verder niet ingegaan op de inhoud van die artikelen op die url, aangezien ik xml als massaal dataopslagformaat totaal kansloos vind...

[TheBorg]

Enige reden die ik kan verzinnen is dat hierarchical data niet echt geschikt is voor db. Aan de andere kant is het ook weer zo dat als je truukjes gebruikt zoals het Nested Set Model, XML boven een aantal regels waarschijnlijk eerder traag wordt dan SQL.

BtM909 schreef op maandag 21 mei 2007 @ 10:30:
XML is niet bedoeld voor opslag, maar voor transport

Dus ik sluit me aan bij het aller eerste antwoord in dit topic. Trek het uit een normale DB en presenteer de resultaten aan Flex op een XML dienblaadje.

[Janoz]

TheBorg schreef op donderdag 24 mei 2007 @ 01:49:
Enige reden die ik kan verzinnen is dat hierarchical data niet echt geschikt is voor db.

Niet voor een relationele database. Een object georienteerde of een netwerk database daarintegen is een stuk beter geschikt, maar die vindt je eigenlijk alleen in academische omgevingen.

[Verwijderd]

Verwijderd schreef op donderdag 24 mei 2007 @ 01:38:
zoals al gezegd is xml een prima formaat voor het transporteren van gegevens en niet voor het opslaan.

Misschien is het een beetje muggeziften, maar transporten is simpelweg een vorm van opslaan. Ook voor transport heeft xml een behoorlijk overhead en doorgaans krijg je het niet eens onder ogen wat betekend dat je geen human readable formaat nodig hebt.

[tss68nl]

tXML kan qua mogelijkheden handig zijn voor opslag. Neem het voorbeeld van een organisatie-hierarchie van een ongedefineerd aantal lagen. Je kan in beide media de data opslaan (Database: Persoon tabel met een veld 'superieur' wat verwijst naar de PK van Persoon. XML: Door domweg in het schema toe te staan dat personen onder andere personen vallen)

De truuk is het eruit halen van dat soort data. Database queries gaan niet erg makkelijk om met een ongedefineerd aantal niveaus in de organisatie structuur. Met opslag in XML kan je met een simpel XSL alle mailadressen retourneren van personen die onder 'Pietje Puk' vallen. Ongeacht waar Pietje in de boom zit, en hoeveel lagen hij onder zich heeft.
Wil je hetzelfde uit een database halen, dan zal je een procedure moeten schrijven welke voor iedere persoon die onder Pietje valt recursief weer gaat zoeken naar personen waar hij de baas van is.

Dus, om domweg te zeggen dat XML geen voordelen bied qua opslag is onzin. Je hoort mij niet zeggen dat er geen nadelen zijn (die hebben jullie al uitvoerig opgesomd), maar er zijn ook zeker voordelen. Laat de persoon zelf de keuze maken op basis van zijn eisen/wensen pakket, het is geen wedstrijd wie gelijk heeft!

[ Voor 0% gewijzigd door tss68nl op 24-05-2007 12:33 . Reden: spelvaut ]

[RobIII]

tss68nl schreef op donderdag 24 mei 2007 @ 12:26:
XML kan qua mogelijkheden handig zijn voor opslag. Neem het voorbeeld van een organisatie-hierarchie van een ongedefineerd aantal lagen. Je kan in beide media de data opslaan (Database: Persoon tabel met een veld 'superieur' wat verwijst naar de PK van Persoon. XML: Door domweg in het schema toe te staan dat personen onder andere personen vallen)

De truuk is het eruit halen van dat soort data. Database queries gaan niet erg makkelijk om met een ongedifineerd aantal niveaus in de organisatie structuur. Met opslag in XML kan je met een simpel XSL alle mailadressen retourneren van personen die onder 'Pietje Puk' vallen. Ongeacht waar Pietje in de boom zit, en hoeveel lagen hij onder zich heeft.

Dat kan in een DB ook prima
(Meer)

[ Voor 9% gewijzigd door RobIII op 24-05-2007 12:31 ]

[tss68nl]

RobIII schreef op donderdag 24 mei 2007 @ 12:29:
[...]

Dat kan in een DB ook prima
(Meer)

Je hebt zelf ook gelezen hoeveel moeite je moet doen om een node te inserten? Herschikken als er halverwege de boom wat veranderd? Nu heb je bij het uitlezen geen probleem, maar bij het opslaan

Goed, mijn punt was ook niet dat het niet *kan* in een database - ik gaf zelfs al een methode waarop het wel kan. Jij geeft een andere oplossing, welke ook omslachtig is. De vraag is of ik ervoor zou kiezen. Draagt niet lekker makkelijk over voor onderhoud bijvoorbeeld Da's een afweging die de topic-starter mag maken. Vooropgesteld dat ie uberhaupt een dergelijk probleem op te lossen heeft

Feit blijft dat er redenen kunnen zijn om voor XML te kiezen. In het geval van hierarchische structuren zou ik zeker die overweging maken, en wellicht zijn er nog andere situaties waarin XML wellicht de voorkeur verdient.

[ Voor 20% gewijzigd door tss68nl op 24-05-2007 14:36 ]

[djluc]

De laatste regel: "Although this procedure works, you might want to use a language that has arrays in it, instead of trying to stick to pure SQL. "

Verder is het een erg uitgebreid artikel om een dergelijk "simpel" iets voor elkaar te krijgen. Niet dat ik xml als database gebruik o.i.d. Wel ben ik bezig met een producten koppeling (met subproducten e.d.) en daarbij werkt XML toch echt super, ook voor die trees.