ANALYSIS SQL vs. XQuery
The
W3C XML Query Working Group has proposed two flexible query languages for extracting data from XML documents: XML Path Language (XPath) and XQuery. XPath addresses parts of an XML document using a compact, non-XML syntax. XPath is a lightweight query language that was actually designed to be embedded in a host language, such as XQuery. It is easy to learn but not substantive enough to replace SQL.
XQuery is designed to retrieve and interpret XML data from any source, whether it is a database or a document. It meets the XML Query Working Group requirements for both human-readable query syntax and XML-based query syntax. Queries are meant to be concise and easily understood. In fact, some have proposed that XQuery become a replacement for SQL. Although it is substantive enough to do the job, it isn't very easy to learn.
XQuery differs significantly from SQL in that it is a procedural language -- SQL is a declarative language. (Not sure what that means? In SQL, you carefully state the result you want, in a procedural language you spell out a series of steps to derive a result.
Here's a longer explanation)
A nonprogrammer can learn SQL. It involves simple declarative commands for what you want to happen; commands are executed and results are returned to you. Using XQuery involves procedural programming in which you define the linear sequence of actions required to generate the results you want. It requires a certain facility with programming logic.
Despite its limitations when dealing with XML, SQL has been heavily invested in by the industry as the standard for searching databases. Some believe that SQL can be adapted to work with XML and so retain its hierarchical properties. In addition, widespread adoption of an XML-based query language like XQuery would require significant retraining throughout the IT community.
So perhaps adopting an alternative query language isn't an ideal solution. The logical alternative is to choose a different type of database that can better handle XML using standard SQL.
Native XML databases
A better solution for storing, retrieving, and processing persistent XML documents is a native XML database (NXD), which understands the structure of XML documents and so preserves their data hierarchy and meaning. As defined by the
XML:DB Initiative, an NXD defines a model for an XML document and stores and retrieves that document according to that model.
The fundamental unit of storage for an NXD is an XML document, the equivalent of a row in a table for a relational database. Because an NXD can be built upon any underlying storage model -- relational, hierarchical, or object-oriented -- an NXD is flexible and scalable. NXDs work best with hierarchical data, whereas RDBMSs work best with tabular data. However, database researchers are working on tiered solutions that deliver the best of both worlds.
NXDs are specifically designed for persistent storage of XML documents. One example is the
Apache Xindice project, an open-source native XML database. The schema-independent model used by Xindice allows you to insert and retrieve data as XML and works well for complex XML documents that would be difficult to map to an RDBMS, let alone retrieve in an understandable way.
NXDs and tiered solutions
A typical three-tier Web application might have a presentation tier in HTML for the user interface; a middle tier housing the business logic; and a data tier with relational, XML, and/or object-oriented databases. These tiers interact with each other through well-defined APIs. In this scenario, the middle tier can be programmed for seamless integration with both RDBMSs and NXDs and so capitalise on the strengths of each. This would be a powerful solution in almost any application where users are retrieving information from various systems. In the content management space, for example, a search engine written to query hierarchical information embedded in an XML database could also query relational information in an RDBMS.
Though we can't yet claim that NXDs will one day replace traditional relational databases, there's no denying that natively understanding XML documents gives the NXDs a distinct advantage in an XML world.