Let XML In
XML documents are crucial to many business applications, and to truly be an enterprise-level database platform, SQL Server must be able to not only store XML documents but to query them and combine XML data with relational data.
April 19, 2004
The next release of SQL Server—formerly code-named Yukon and now officially named SQL Server 2005—will provide deep XML integration with the SQL Server database engine. This integration will go well beyond the simple relational-to-XML mapping layer that SQL Server 2000's SQLXML Web releases enable. SQL Server 2005 will feature a native XML data type, XML indexing, a new XQuery language, and a graphical XQuery Builder. Microsoft has also tapped XML as a core component in its platform-integration story (in answer to Java's cross-platform support) and added XML support to many key enterprise products, including Visual Studio .NET and Office 2003.
But not everyone is enamored with the idea of including XML in his or her relational database. Some people—whom I refer to as relational-database purists, or purists for short—see XML as a foreign entity that has no business in the relational database. And some of their arguments have merit.
Purists view XML documents in much the same way they view HTML documents. You wouldn't store Web pages in a relational database, so why store XML documents there? Purists are also correct in pointing out that you currently have two ways of using XML documents with a relational database: You either shred the XML documents into relational data that you then store in tables and columns, or you store the entire XML document. Shredding XML at least stores the data in a relational fashion. But requirements for the fixed-document format are at odds with XML's hierarchical nature—not to mention that the shredding process is fragile and easily broken by unexpected document changes. Storing the entire XML document in the database is no better in the purist's view because the database can't query the XML document. Instead, you must retrieve the XML document, then have another application parse it before you can use the document's data.
However, SQL Server's next release will dramatically improve the process of working with XML data and documents. XML documents—as related pieces of business information, just like binary large objects (BLOBs)—belong in the database, even if you're only storing them. The database must be able to store all the data that an application requires.
The SQL Server 2005 database engine extends the database's basic storage capability by letting you directly query and update data in XML documents that you store by using the XML data type. SQL Server 2005 uses the same query engine and optimizer for querying XML data as it does for relational data, radically enhancing your ability to work with XML data. (For details about the new XML data type and XML query improvements, see Rich Rollman's "Yukon's XML Data Type," December 2003, InstantDoc ID 40482.)
The role of the relational database is no longer to serve as simply a repository for character and numeric data. Today's applications require a variety of information types, including character, numeric, BLOB, and XML data. XML isn't an evil force to be kept out of the sacred relational database. XML documents are crucial to many business applications, and to truly be an enterprise-level database platform, SQL Server must be able to not only store XML documents but to query them and combine XML data with relational data. With SQL Server 2005's deep XML integration, Microsoft is providing this important functionality.
About the Author
You May Also Like