VNC stopt er mee :(
xml gegevens..
Ik ben bezig met een plattegrond:
Alleen nu kijk hij nog niet naar de gegevens. Want op het coordinaat (14|14) kan een stad staan.
Nu wil ik die gegevens opslaan in xml.
Omdat ik het met database wel kan en ik iets nieuws wil proberen.
Dus dan moet ik elk vakje waar iets in staat opgeven in xml document.
Ik heb me daar nog niet echt in verdiept dus correct me if im wrong
zoiets:
Code (php)
1
2
3
4
5
2
3
4
5
<vakje>
<coord>437|343</coord>
<soort>stad</soort>
<image>stad.jpg</image>
</vakje>
<coord>437|343</coord>
<soort>stad</soort>
<image>stad.jpg</image>
</vakje>
dat wou ik dan gaan uitlezen via simplexml..
Maar doe ik dit wel goed?
Of is er een snellere/betere manier in het storen van de gegevens(wel met xml)? (ik wil geeeeeen database omdat ik ook xml feed wil)
Graag beetje uitleg :-)
Groeten, Vincent.
Gewijzigd op 01/01/1970 01:00:00 door Vincent
Dat lijkt mij niet goed, 2 gegevens in 1 record.
Met kaarten heb je altijd een x- en een y-as, evt. ook een z-as voor de hoogte, dus heb je 2 (of 3) tags nodig om deze gegevens op te slaan.
Maar, ga dit in een database opslaan en niet in XML. XML is onvoorstelbaar langzaam wanneer je dit vergelijkt met een database. XML gebruik je als interface met andere systemen, bv. een RSS-feed of SOAP. Het feit dat je een RSS-feed wilt opzetten, zegt niks over de dataopslag in een database. pgSQL kan bv. ook prima XML inlezen en uitspugen (met stored procedures). Al is het waarschijnlijk handiger om dit met PHP te doen en dan via PDO met de database kletsen.
De RSS-feed is gewoon een andere output dan bv. html, pdf of een email, meer dan dat is het niet.
Inderdaad is een database wel de slimste oplossing, maar daar gaat het nu even niet om. Tevens heb ik even wat aangepast, zodat je niet gegevens overbodig opslaat. (soort stad en dan plaatje stad.jpg -> Simpeler, lees soort uit en dan soort.jpg is het plaatje)
In principe zou je het met deze gegevens moeten kunnen redden:
<vakje>
<xcoord>437</xcoord>
<ycoord>343</ycoord>
<soort>stad</soort>
</vakje>
Wel leuk al die vliegvelden erop, maar dan staat Schiphol er niet tussen (gaat over het gebruikte plaatje!)
De bedoeling was(want t is voor school) dat ik met ajax leer omgaan.. en toen wou ik er ook xml bij doen, vandaar dat ik dit doe :-)
In combinatie met ajax kun je hele leuke dingen doen met XML. Ik gebruik bv. stored procedures in pgSQL die direct XML aanmaken als resultaat en dan gooi ik de boel direct naar de browser:
Code (php)
De ene resultaatregel wordt gefetched, voorzien van een header en uitgespuugt. De browser gaat de boel vervolgens netjes verwerken en in een formulier zetten.
Niels. schreef op 01.12.2007 17:53:
Dit zegt 10x niks, je hebt geen idee hoe complex een query kan zijn of hoe groot een database kan zijn. Wat dacht je van een database van 10TB en vele miljarden records verspreid over een paar honderd tabellen? Ga dan maar eens data halen uit een tabel of tig met een paar leuke joins. Dat kan echt wel even duren, ga ondertussen maar koffie halen!Ehm, als jouw database er 0.1 seconde over doet om een antwoord terug te geven zou ik toch gaan zoeken naar een andere host! Zelfs mijn laptop geeft nog een groot antwoord terug in minder dan 0.0001 seconde.
Een query die er 0.1 seconde over doet, kan dus razendsnel zijn, maar ook rete langzaam. Het ligt maar net aan de complexiteit en grote van de database wat je snel of langzaam vindt.
Met XML wordt het in elk geval al heel snel te langzaam, dat is vanzichzelf al langzaam.
Het is maar een ideetje... Wel een die tijd gaat kosten maar het kan zeker zijn vruchten afwerpen!
Ik ben het niet eens met je voorkeur voor een db ten opzichte van xml gebruik.
Als je veel traffic hebt met veel bezoekers is het vele malen efficienter om een xml-tje gebruiken dan voor al je bezoekers een db connectie te maken en de zelfde query uit te voeren.
Al zou ik dan sowieso geen xml gebruiken, maarja. Plaatsen zullen niet zo snel veranderen en ook niet heel snel erbij komen, dus je kan het dan gewoon nog beter hardcoded in je pagina's zetten.
Leuk propeerseltje in ieder geval met xml.
En in een 2d plaatje komt geen z-as voor.
Tuurlijk, een XML-bestandje van 3 regels is sneller dan het openen van een database connectie, versturen van de query, ophalen resultset en fetchen van een resultset. Maar om dat nu een realistische situatie te noemen... Hooguit voor een configuratiebestand, wat ik dan ook wel eens gebruik.
XML is eenvoudig met Schema te valideren, dat heeft enorme voordelen, voorkomt een hele hoop bugs.
Quote:
Support for the SQL/XML standard, including new operators and an XML data type
Versie 8.3 is nog in Beta (versie 3, hopelijk de laatste voor RC1), leuk om mee te spelen maar ook niet meer dan dat. Voor productietoepassingen zul je dus nog even geduld moeten hebben. Hopelijk nog dit jaar, Q3 2007 was de oorspronkelijke planning.
Kalle: t is meer iets voor school dus niet echt om de bezoekers
pgfrank: wat vind jij een "flink" xml bestand? en is er trouwens een soort usbwebserver met pg?
Gewijzigd op 01/01/1970 01:00:00 door Vincent
De definitie van 'een flink XML bestand' is een beetje afhankelijk van de hoeveelheid geheugen die jouw server tot zijn beschikking heeft, maar met een paar honderd MB loop je met XML al wel tegen flinke beperkingen aan. Je hebt namelijk als snel 2x zoveel geheugen nodig wanneer er bewerkingen plaatsvinden en het overgrote deel van het geheugen wordt door andere zaken dan de data ingenoemen.
Voorbeeldje:
Code (php)
1
2
3
2
3
<adres>
<huisnummer>23</huisnummer>
</adres>
<huisnummer>23</huisnummer>
</adres>
Zie hier het aantal karakters dat je nodig hebt om het nummer 23 op te kunnen slaan... Tuurlijk, het is een extreem voorbeeld en ook een database heeft overhead, maar dat is vele malen minder dan met XML. Daarnaast kun je geen indexen aanmaken. Stel je voor dat je 1000 complete adressen moet doorlopen om alle adressen in Amsterdam op te zoeken. Dat gaat 1-voor-1 en niet alleen op een index.