xml questions

pcthuglife

Member
May 3, 2005
173
0
0
Im having a hard time wrapping my mind around XML. I understand that its a pretty universal language that can be used to sort any kind of data you can imagine. But why would I choose to use XML over something thats database driven (MySQL, PostgreSQL)?

What is the benefit to storing data in custom tags vs storing data in a database table? XML documents seem static, is that really the case or can you make content management apps that update your XML files automatically?

I started reading a few books (very basic) on XML because I wanted to learn something new, I just can't see the real benefit to using XML files over a MySQL database. Are there any experienced XML programmers that could shed some light on the full potential of XML ? Thanks.
 

replicator

Senior member
Oct 7, 2003
431
0
0
XML isn't meant to replace a full blown database, but for instances where you don't have concurrent users that updating information, it can work too.

The heart of XML is that is it simple to use and very lightweight since it can be readable by a human. Many applications use hand coded XML for configuration, especially ones that are Java/.NET related. (J2EE->Welcome to XML Hell).

The real benefit comes to organizations that use EDI (Electronic Data Interchange) to communicate with their buyers/suppliers. Before it was very expensive to set up a new partner to the network since most companies used different protocols and data formats. With XML, and especially web services, it is much easier to integrate systems.



 

kamper

Diamond Member
Mar 18, 2003
5,513
0
0
So far xml's benefits haven't come so much as a long term storage mechanism. It's more beneficial for standalone files (frequently a document format, like xhtml or docbook or something) or as a transient container of data (SOAP messages and other various shortlived pieces of xml).

There may be a couple of reasons for that but the biggest one is that relational databases are way more mature. They have good manipulation languages (sql plus proprietary dialects), transaction support, scalability... That stuff just isn't there for xml yet (the standards are coming along but after standards you must have implementations) so using it as a reliable and manipulable storage mechanism isn't easy.

Another issue is the whole storage paradigm. Traditional databases are relational and there's a tonne of industry momentum around that pattern. I'm not sure what the real term for xml storage is but I guess you'd call it hierarchical. Generally programmers aren't as familiar with xml-type storage ideas, although it does fit better with object oriented programming, since objects are laid out a little more similar to xml than tables (it's not a perfect match).

Anyways, storing xml can be useful if you are wasting too much time designing and updating a relational schema. In that sense, xml is sortof like a scripting language where a relational schema is a compiled language. You can put anything you want in there, but if it's invalid you might get runtime errors. The project I'm working on right now at work stores xml documents as text in a database. The documents model a questionnaire which we show on a website and designing (and maintaingin) an xml schema was far more light-weight than a relational one. If the document structure changes after deployment then we have to go through the hassle of updating every single document that's been stored and that's one of the tradeoffs. Hopefully as real xml databases become available this process will become a little easier.

Personally, I've been looking into an xml database named eXist. It stores and indexes xml documents and you can query/update it with a number of relatively cutting edge xml manipulation languages. Haven't actually written anything against it yet though.