Re: PHP with XML database

Thank you Bernhard and Richard Your comments have been really helpful. I have a meeting with the professor on Wednesday and I will lay down all this points in front of him then. On 1/29/07, Richard Lynch <ceo@l-i-e.com> wrote:

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?

-- Ritesh http://www.riteshn.com