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.

End of Article




You must log on before posting a comment.

If you don't have a username & password, please register now.

Reader Comments

I think good idea to store XML data directly in SQL Server. Arguments like that "XML as a foreign entity" are not rightful, SQL Server for a long time not only relational database.

Alexander Koshelev

Dismissing those of us who do not like the idea of XML in our databases does not make us wrong.

XML proponents tend not to even realize that they are sprinting headlong into the past of hierarchical data management which was proven to be inflexible and inefficent decades ago.

"Purists" as you lable us, are not simply driven by a reflexive hatred of anything new, we do not like XML because it does not bring with it any appreciable benefit that other methods do not already provide, and at a lower cost. XML is horribly inefficient by any measurement, and it is downright catastrophic in terms of data management. As rudimentary as the data integrity capabilities are of todays SQL based DBMS's are, they put XML to shame.

Anyone who understands and cares about data quality and independence will completely shun the use of XML, particularly when the ignorant (those who will not learn the lessons of the past) want to use a relational based system to store and manage it.

Don Peterson

How DBA's functionality is rapidly chinging with the change of SQL server version, should bematerilized in the next release of this magazine.

Shahidul Haque