Michael Champion's Blog

Reports of the "Demise of the XML Database" are dubious

Phil Howard of Bloor Research presents anargument I've heard more than once recently: "The reason why there is this trend away from pure XML storage is because advanced XML capabilities are being introduced by all the leading relational vendors." As the developers of Object Oriented DBMS discovered, he says, "the truth is that (like it or not) the market will make do with what the relational database products offer".

If analysts are already inviting themselves to the funeral of the XML DBMS, maybe we should check to see if the departed is lying quietly waiting to be buried. Perhaps like the unfortunate Lal Bihari of Uttar Pradesh in India, it been declared dead by those who would prematurely appropriate its inheritance. Here's a few arguments for their continued viability:

• It is widely believed that less than a quarter of enterprise data is currently stored in RDBMS systems. This suggests that the market is not "making do" with what the relational database products offer today, but using a wide variety of technologies.
• The main reason OODBMS didn't hit the sweet spot, AFAIK, is that they created a tight coupling between application code and the DBMS. Potential performance gains this allows can outweigh the maintenance challenges in extremely business critical, high transaction volume environments (e.g. where IBM's IMS or Software AG's Adabas DBMS still thrive), but not in the kinds of innovative, rapidly evolving environments where OODBMS got a foothold.
• XML DBMS, on the other hand, inherit XML's suitability for loosely coupling systems, applications, and tools across a wide range of environments. Phil Howard mentions "integration" as if it were a niche. That may be true in a business sense, but the ability of the XML DBMS to efficiently, scalably, and reliably power the intrinsic integration-friendliness of XML is likely to find a wide range of uses outside the "application integration" business space.
• Again AFAIK (having only played with OODBMS personally), there is relatively little portability across OODBMS systems; code written for one would be very expensive to adapt to another. Investing in the technology required one to make a risky bet on the vendor who supplied it. This created an environment where the object-relational vendors could prosper by offering only a subset of the features but the absolute assurance that they would be in business for years to come. In the XML DBMS world, on the other hand, all support roughly the same schema, query language, and API standards;
• The standards of the XML world provide a clearly defined and fairly high bar for those who would seek to take away the market pioneered by the XML DBMS vendors. For better or worse, the XML family of specs is complex and quite challenging to support efficiently in a DBMS system. It's one thing to support, as the RDBMS vendors now do quite well, XML views of structured, typed, relatively "flat" data such as are typically found in RDBMS applications. It is quite another to efficiently and scalably support queries and updates on "document-like" XML with relatively open content models, lots of recursion, mixed content, and where wildcard text comparisions are more frequent than typed value comparisons. The dominant DBMS vendors obviously have talent and money to throw at the problem, but analysts should not assume that they will surpass theese capabilities of the XML DBMS systems anytime soon.

This is not to predict the demise or even decline of the one-size-fits-all RDBMS+kitchen sink products from the dominant vendors. Microsoft's Longhorn project apparently hopes to handle much of the other 75% in an RDBMS-powered but XML-capable replacement for the filesystem. As much as one can admire this vision and expect it to be at least partially successful, there will be an awful lot of "pure" XML data out there, partly due to Microsoft's other efforts. A substantial number of developers and end-users will continue to need "pure XML" DBMS technology that handles XML extremely well, even given the availability of DBMS technology that handles all kinds of data in a "good enough" way.

Finally, it's important to consider the gap between technology mindshare among pundits and analysts, and technology deployment by businesses who need to get the job done efficiently and reliably. I'm reminded of another technology analyst who has dismissed XML itself by pointing to its similarities to IBM's IMS product, a "discarded in practice" hierarchical DBMS. So IMS is also dead, eh? Let's see ...IBM says "IMS serves 200 million end users, managing over 15 billion Gigabytes of production data and processing over 50 billion transactions every day." Another corpse that won't quietly play its part in the funeral the analysts have thrown for it!

I'm not sure when pure XML databases will be managing exabytes of data, but It looks to me like XML DBMS's will join IMS and Mr. Bihari in the ranks of those who continue to lead active and productive lives despite having been declared "legally dead" by the presumed authorities.

Comments

• less than a quarter
  This is because the other three-quarters are in buried in Excel spreadsheets... ;)

  Posted by: zoe_info on October 05, 2003 at 02:29 AM

• Useless design.
  The reason you want to use a database to store your data is because it has to be correctly structured. This is the first and formost reason to use any DB.
  Searching fast comes at a distant second place. (and is kinda implied by the first anyway).

  XML databases are a solution to a non-existing problem.
  Or, maybe more accurately, it allows you to NOT use the most wanted feature in a DB.

  The effect is a evolutionariy one, using a solution that allows you too much freedom spreads the ruleset that should be in the DB to the whole application. Making the whole application too hard to maintain. In the end it kills your application.

  Hence the very low pickup.

  Posted by: zander on October 05, 2003 at 07:49 AM

• Useless design.
  Well, people use XML for all sorts of reasons, good and bad I suppose. The point of an XML DBMS as I see it is to securely, reliably, transactionally, scalably, etc. manage that XML, whether or not it is "correctly" structured.

  Even if the data is well designed and "correctly" structured, the schemas are not necessarily available to all the software that must process the data downstream. For example lots of "middlware" will need to keep track of the messages coming through, and will sometimes need to do fast searches for auditing purposes (who forwarded that fraudulent order, anyway?), message correlation (what message is this one in response to?), and so forth. One might lament the fact that XML is the format in which enterprise messages are increasingly being sent, but that's the reality that many developers will have to deal with, and my argument is simply that "pure" XML DBMS are well suited to the task.

  The point about "too much freedom" is a plausible one, and perhaps someday our descendents will regret us going down this path. I for one doubt that will happen, and in any event the RDBMS vendors let that horse out of the barn long ago -- perhaps from the beginning by standardizing on SQL rather than a "pure" relational language, and certainly a decade or so when they started handling BLOBs, CLOBS, objects, etc. If there was a low demand for scalable XML storage, why are the RDBMS vendors falling over themselves to add XML to the menu of unstructured stuff that they can handle? The argument in the article I'm critiquing is that the RDBMS vendors can handle the demand and marginalize the XML DBMS vendors, not that there is no demand.

  Posted by: mchampion on October 05, 2003 at 08:23 AM

• Useless design.
  > If there was a low demand for scalable XML storage, why are the RDBMS vendors falling over themselves to add XML to the menu of unstructured stuff that they can handle?

  Because there is a high need for storing unstructured data in a structured manner.
  I like being able to have custom text-types and lenghts per client and just put all the stuff in an XML in my DB. As long as I can find it to belong to that client. And I typically will never search in that unstructured data (since its unstrucutred..).

  Having only unstructured data (from the POV of the DB) is quite useless. And this is what the author is indeed arguing with his option to have XML being searched in memory, which makes perfect sense.

  > The argument in the article I'm critiquing is that the RDBMS vendors can handle the demand and marginalize the XML DBMS vendors, not that there is no demand.

  As humans (and engeneers are even worse) go any solution will find a problem.
  The point is that regular vendors (and I do think mature OpenSource ones fall into that catagory) can provide the thing most people want. Which is to store XML.

  So, from the point of view of the customer; an XML (or OO) DB only takes away possebilities, it does not add anything.

  I must say that I am the main author of a (closed source) OO-2-SQL layer for Java, this gives me all the power I need for persistence and much more.

  Posted by: zander on October 05, 2003 at 12:11 PM

• wow power leveling
  wow powerleveling
  wow power leveling
  wow gold
  wow items
  feelingame.com
  wow tips
  Most Valuable WOW Power Leveling Service
  wow power leveling faq
  cheap wow power leveling
  wow power leveling
  wow powerleveling
  wow power lvl

  Posted by: wowleveling3 on December 13, 2007 at 06:11 PM

• 网络营销软件
  网络营销软件
  网络营销软件
  群发软件
  群发软件
  ---
  群发软件
  网络营销软件
  论坛群发软件
  网站排名软件
  群发软件
  推广小助手破解版
  论坛群发软件
  网站排名软件
  群发软件
  网络营销软件
  网站推广软件
  信息群发软件
  论坛群发软件
  信息群发软件
  博客群发软件
  qq群发软件
  邮件群发软件
  博客群建软件
  企业名录搜索软件
  信息群发软件
  邮件群发软件
  论坛群发软件
  博客群发软件
  网站推广软件
  网络营销软件
  全能营销破解版

  Posted by: bininine on December 16, 2007 at 01:20 AM

This work is licensed under a Creative Commons License.