Why do I want to use XQuery against relational databases?

August 15, 2007 Data & AI

A few days ago someone brought to my attention a post by Elliotte Harold about "The State of Native XML Databases", which also mentions DataDirect XQuery: "DataDirect XQuery is not itself a database. Rather it is an adapter layer that sits on top of your existing payware database such as SQL Server or Oracle and provides an XQuery interface. Why you’d want to use XQuery instead of SQL when talking to a relational database, I’ve never quite been able to fathom. Data Direct XQuery also has adapters for XML files, EDI, and other flat files."

Why would I want to use XQuery when talking to a relational database? I've spent a good portion of my last two years demonstrating how DataDirect XQuery can be used to solve problems that also require access to relational databases; so, let me describe a few usecases I have seen; in all of them, being able to use XQuery rather than Java+SQL makes developer's life much simpler and productive.

I need to query my database to generate XML documents We have recently published a customer story about this; it's not infrequent that data needs to be transferred/communicated in XML format. So, even when the data is all stored in relational databases, SQL (plus whatever language around it to "massage" the data) is not necessarily the easiest path to generate XML representing portions of the relational data. The customer in question has commented on some quantitative comparison between *how much* easier it is; it's not difficult believe it if you know the technologies in question.

I need to process an incoming XML message and respond including data stored in my database
This is a very frequent usecases; in some cases instead of receiving an XML request the user is dealing even with EDI; but there are tools that make the conversion of EDI to XML quite easy, so the problem ends up really being the same. How would you address that problem without an XQuery processor able to handle relational database access? You would probably write a Java application that parses the incoming XML document, even these days most likely you would materialize it in an XML DOM, fetch the information you needs from it, issue SQL queries over JDBC to get more related information, and finally you would create an XML document to return the requested result(s). We did try implementing this exercise dealing with some ACORD XML requests, and a relational back-end storing the various insurance policy details; we will soon publish more information and code samples on http://www.xquery.com/; in the meanwhile, I'll need to leave it to your imagination how the Java code looks like, and how it compares to the equivalent XQuery+Java code that would achieve the same goal using DataDirect XQuery.
I need to shred the content of my XML document into my database
This is one of the reasons why we have added RDBMS update capabilities in the latest version of DataDirect XQuery; it is another quite popular usecase. Again you are dealing with the necessity to navigate an XML document, find the proper information in there, and then execute operations against a relational database based on that information. Once again the same problem can indeed be solved using Java+SQL+some XML API; but isn't it more productive to use an XML native language featuring the ability to access both XML and relational data in the same context?
To wrap up, I believe the real question I would ask myself is not "Why would I want to use XQuery when talking to a relational database?", but rather "Can I use XQuery to access a relational database achieving the same levels of scalability and performance that I could achieve using a combination of Java and SQL?". That's exactly where the difficulty is, and where XQuery implementations differ dramatically. Of course it would be easy for me to answer "Sure you can! DataDirect XQuery has been designed exactly with that goal in mind!"; and I could point you to a variety of literature on http://www.xquery.com/ (the most interesting one being probably this one by Marc). But instead, I encourage you to try it yourself; get a fully functional trial version from http://www.xquery.com/download, and give it a try, using your own usecase, your own database and your own data set. That's the only way you will actually experience how XQuery can make things easier for you without scalability and performance compromises.

digg_skin = 'compact';

Minollo