Wednesday, July 21, 2004

XQuery or SQL

SQLfX: Is It Progress Or Piffle? "“XML is important enough that it’s pulling the SQL market apart,” asserted David, expressing concern about the proprietary solutions that have emerged from the so-called big three database vendors, which have largely ignored David’s ideas. “IBM, Oracle and Microsoft are all very different in how they approach XML support, and each requires training. If you want to combine or pull data from two of those products, you have to learn those two.”"

"“With XPath calls, you go down one leg at a time,” he said, with manual coding required to traverse more than one leg at a time. “XQuery’s FLWR statement has loop statements. But you’d have to do your own correlation between paths and set up a different path call on each leg, and that gets complex.”"

"At the heart of SQLfX, which David expects to release in mid-2005, is SQL’s “outer join” operation. This brings two hierarchical structures together as a means of coping with XML’s nesting. “If you’ve ever looked at two legs of an org chart to see how they’re related, that’s what this does. The user doesn’t have to know the structure; they just need to say what data they need.”"

"“Because XML documents can and often do have a large maximum depth of nesting, with 10 or 15 levels not uncommon,” Melton continued, “a combination of 10 to 15 outer joins would be required to reassemble the data into a hierarchical representation,” which he said is enough to make many SQL engines bog down.

Ironically, David claims to address these inefficiencies with proprietary algorithms."

So, there is a similar debate in the database world about using XQuery over SQL to query XML.

The use case for multiple paths in a hierarchy, is similar to the Optional Match requirement in the DAWG. With RDF, of course, it's graph matching not multiple hierarchies.

With respect to querying RDF, I'm not sure that there should automatically be only one type of syntax. Currently, the DAWG is focused on the use cases and the required operations to meet these use cases. Then I'm sure the group can make a judgement as to how it could be expressed functionally (like XQuery does for XML) or declaractively (like in a BRQL/iTQL way).

Another problem that was brought up in our discussions at work was with the return syntax in XQuery. Applying some of the syntax of XQuery to an RDF query language, it would have to describe returning either a graph or some sort of list of results. This seems to be mixing the binding of results with the presentation of the results.

Paul's most recent blog discusses some of the issues, especially as Network Inference continues to make the claim that RDF is "grounded" in XML.

No comments: