Archief - XML vs SQL

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

Shaddix

Legacy Member
Ik ben momenteel bezig met een mobiele drupal website.

Voor deze website zou er op een bepaalde pagina een stukje informatie moeten te zien zijn die uit een xml file komt.

De XML file is bestaat zowiezo al en verandert +/- 1x per week. De file is +/- 1,1MB groot. Er zitten dus enkele honderde nodes in, met elk een datum. Bij elke page view worden er 2 tot 10 nodes uit die file gezocht en getoond afhankelijk van de datum.

De mobiele pagina zou toch wel vrij frequent gebruikt worden.

Is er nu veel performantie verlies als die file met XPath/PHP wordt geparsed? Of is het in dit geval écht aangeraden om die file bij elke update in de database te importeren?

adrianhates

Legacy Member
omschrijf vrij frequent..

Spreken we hier over 1000 pageloads of 10 000 000 pageloads / dag?
In het eerste geval zal het verschil zowiezo verwaarloosbaar zijn.

Ge moet zowiezo van file lezen dus veel verschil zal er niet op zitten..

Misschien dat het zoeken in de file wel kan tegenslagen vs zoeke in een db omdat ge daar met indexen zit, maar wederom hangt dat af van het aantal nodes in uw xml vs het aantal records in uw db table.

Shaddix

Legacy Member
frequent = meermaals per minuut

mijn bekommernis is dat MySQL al jaren performantie nastreeft en dat dit daardoor dus misschien wel eens een pak sneller kan gaan en minder resources in beslag nemen

Sick-Boy

Legacy Member
Dat hangt er van af hoe je de structuur van de databank indeelt en hoe je ze aanspreekt.
Als je de resultaten toont afhankelijk van de datum, betekent dit dat als ik vandaag op jouw pagina kijk, ik steeds dezelfde pagina zie?
Dan kan je misschien elke nacht een statische pagina laten genereren op een rustig moment. Dit is maar een idee, ik weet niet of dat goed komt met caches enzo.

Gurdt

Legacy Member
Als uw XML-file honderden nodes bevat, is het misschien niet echt aan te raden? Kunt misschien wel overwegen die file te splitsen op datum, en dan afhankelijk van de datum een andere file gebruiken?

Shaddix

Legacy Member
Gurdt zei:
Als uw XML-file honderden nodes bevat, is het misschien niet echt aan te raden? Kunt misschien wel overwegen die file te splitsen op datum, en dan afhankelijk van de datum een andere file gebruiken?

daar is het helaas te dynamisch voor

Sick-Boy zei:
Dat hangt er van af hoe je de structuur van de databank indeelt en hoe je ze aanspreekt.
Als je de resultaten toont afhankelijk van de datum, betekent dit dat als ik vandaag op jouw pagina kijk, ik steeds dezelfde pagina zie?
Dan kan je misschien elke nacht een statische pagina laten genereren op een rustig moment. Dit is maar een idee, ik weet niet of dat goed komt met caches enzo.

dat waren we inderdaad aan het overwegen, we zoude de file niet enkel in datum maar ook in categorie kunnen opdelen waardoor het al een stuk compacter wordt

dJeez

Legacy Member
Daar hebben ze nu benchmarks voor uitgevonden zie :p. Nee, alle gekheid op een stokje, dit kan je toch perfect zelf gaan meten? Maak een voorbeeldbestand in XML (mag ook echte data zijn uiteraard), laat daar apache bench (of iets gelijkaardigs) op los, herhaal het proces enkele keren en neem nota van de resultaten. Doe dan hetzelfde maar met een DB alternatief (check dat zowel met MySQL als SQLite - die laatste zou je wel eens kunnen verbazen als het puur om lezen van data gaat). Vergelijk dan de resultaten en ga voor de beste oplossing...
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan