On Fri, January 26, 2007 6:10 pm, Ritesh Nadhani wrote: > Hello > > Bernhard Zwischenbrugger wrote: >> Hi >> >> Some questions >> >>> As part of my research under my professor I have to implement a web >>> interface to their benchmarking data. >>> >>> PHP is the chosen web language but we are little worried about the >>> database. The benchmark data comes to us in XML format (e.g. >>> http://www.matf.bg.ac.yu/~filip/ArgoLib/smt-lib-xml/Examples/FolEq1.xml). >>> We have to implement an interface to query them, get data, update >>> etc. >> >> You can parse the XML, extract the data, put it to an SQL DB and >> move >> the XML to /dev/null (delete it). >> If you do that, you don't need an XML DB. >> Is this possible? >> > > No. My professor is dead against that. Many people have suggested me > doing that. Why? Are XML databases incorrectly implemented or are bad? I think it's safe to say that at least some XML databases are incorrectly implemented, or even bad. :-) The answers you keep getting are because without a driving reason to use the features specific to XML, using XML as the database backend is probably a Bad Idea. So unless you explain WHY you want the XML db, and unless those reasons make sense to need an XML db, you'll keep getting people telling you, effectively, to "Don't do that." >>> We even can change schema in the form of attributes. . The data >>> size >>> would be around 100 MB each XML with around 100 different XMLs. >> >> What do you mean by "different XMLs"? >> Are you looking for a maschine that makes SQL Tables from XML? >> What is inside of the 100MB XML? Your example is a MathML Formula. >> > > By different XMLs I meants, different XML files. So we can have 40 XML > files with around 50-100 MB each. > > Yes, they will have lot sof those MathML formulas. Its benchmarking > data > from some theoritical group that my professor works with. They have > all > their database in XML so relational database is not possible otherwise > we will have to convert them between XML and relational all the time. How exactly will your converted XML get folded back into the other data stores?... This is your big challenge, upon which everything else hinges. >>> The load would be max 5-10 users any given time, batch updates once >>> a >>> month and heavy load probably 2-3 times a month. Mission >>> criticality is >>> not important, we can get it down sometimes. Which db would you >>> suggest? You have to define "heavy load" unless your max 5-10 *is* the "heavy load" in which case you'd have to work hard to screw this up enough to not be able to handle the load, I think... Though I dunno for sure what performance of XML backend is like... >>> I did Google research and as of now - I like eXist, Sedna (they >>> seem to >>> have good PHP wrapper support) and Timber. Another thing would be >>> good >>> documentation and support. I've never even heard of eXist nor Sedna, which is why I'm suggesting you choose something a bit (okay a LOT) more mainstream like MySQL, where you'll have zillions of fellow users to help out. > So my question is: out of the six systems listed above, which one you > would suggest? Has anybody used any of the above system before? What > are > your experiences? I've never actually been silly enough to insist on storying actual data as XML and pretending it's a DB, rather than storing it as DB and then writing scripts to output it as if it were XML... Unless you've got shared data segments scattered all across the world, forcing it all into XML is probably the First Mistake. But since that's your professors' problem, and not yours, I can see how you've got little choice in the matter. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
