What Do You Know About Databases And XML?

Dare Obasanjo writes: "XML has become a pervasive part of significant segments of software development in a relatively short time. From file formats to network protocols to programming langauges, the influence of XML has been felt. I have written an overview of XML schemas, XML querying languages, XML-Enabled databases and native XML databases. Below is a shortened version of the article." Obasanjo's original OODBMS article has been updated to reflect more of the disadvantages between picking an OODBMS over an RDBMS.

Comments

Re:xml is an interchange format, not a storage for

[sphealey]

Why is NASA switching to MySQL from Oracle [fcw.com] and noticing speed increases?

I will defer to you on the advantages/disadvantages of using databases to store OO data.

However, citing NASA as a source for technology or trends is a bit silly, for a number of reasons. The primary one is this: NASA is so large, and so diverse, that at one of their sites/on one of their projects they use one of just about every technology product you can name.

I was once running two back-to-back software evaluations for products in the $20-million range. For both applications, the top ten vendors all claimed that their system was "used by NASA for the Space Shuttle". We checked up and guess what - they were all telling the truth.

So you need a better example.

sPh

Missing the Big Picture

[SuperKendall]

I can't believe no-one has posted my standard response to someone who thinks XML is just for "interchange".

The interesting thing about XML to me is NOT that it solves the interchange problem (though it helps with that). The great thing is that it solves the PARSING problem. No longer do I have to write a parser everytime I have some simple task of reading in something externally.

What XML does is define for you a standard means of parsing, and by defining the API for parsing and the structure of the documents lets you think about how you want to structure external information, not how you're going to read it in.

Also, because the API for parsing is now hiding the engine details below, parsers can be specialized depending on what kind of task you have. Parsing thousands of 1k XML documents would seem to demand a different processor altogether from a few multi-GB documents, but you only have to know one parser (Ok, really two - SAX and the DOM interface). You could even have specialized XML processors that did write the stream out in a wierd custom binary format for compactness and read it back in with the normal DOM API so clients wouldn't have to adjust. I'll grant you that there don't seem to be many specialized XML processors - yet.

I also like the robustness of XML exchanges (here I'm getting more into your main point). If you add or drop attributes from an XML document, clients that read that document are less likley to break (unless of course they relied entirely on the node(s) you have removed!). That is especially true of XSL, where missing nodes of a document simply correspond to missing parts of output (which can also be a useful effect).

You might think of XSL as a useless language, but I'll be happy to make a counter-prediction that it will grow and thrive. It's simply too useful a transformation tool to do anything else. I know the syntax seems overbearing, but for the kinds of short transformational work it's normally put to that's not much of an issue and you get used to it quickly.