SQL Server and the XML Love Affair

One of the main questions that’s probably on your mind is, why do I need XML if I have T-SQL? Are they two separate languages that SQL Server supports, or are they like the doubles partners of a tennis match-where they each have their respective strengths and weaknesses that combine to make it game, set, and match? This section explains how the two languages coexist and how XML caters to the shortcomings of traditional methods of storing, manipulating, and analyzing data.

T-SQL Versus XML or T-SQL and XML

Does XML replace T-SQL, and if not, how are the two technologies used together or interchangeably? The answer to the first question is straight and easy: No, XML does not replace T-SQL. In order for us to send and receive data to and from SQL Server, we need to use T-SQL in the same manner that we use T-SQL to retrieve ADO.NET datasets right now. Because XML is primarily the way our data is defined, T-SQL is still the language of choice to talk to SQL Server. No two ways about it. We will explore the many ways that T-SQL and XML can be used together to produce robust SQL-XML solutions, and I think you will see that XML alone cannot really do anything all by itself. XML needs help in formatting, data retrieval, and data manipulation.

So you might ask, why do I need to use XML if it cannot do everything all by itself ? Well, in the past, we still had all of these problems with different data formats, poor data description, and the need to continuously worry about what our client was sending us. As we have stressed before, XML solves this problem by being self-describing. Self-describing data makes life easier: no more custom applications to convert every single type of data format we receive. Furthermore, XML is highly optimized for electronic transmission.

Marshaling large ADO recordsets across the wire caused poor application performance and network bottlenecks. With XML, the data is streamlined for transmission over media such as the Internet, in XML constructs such as ADO.NET datasets. In conjunction with the server-side processing of SQL Server, and with the combination of T-SQL, XML, and other client-side programming languages such as Visual Basic 2005, JScript, C++ (.NET), and C#, we have all the tools for creating the most robust solution that we possible can. We are, however, leaving out a very important point. Imagine this: Oracle, DB2, and SQL Server all supporting XML natively The conversion and incompatibility problems between all database servers will go to hog heaven. No more driver problems, or language differences between PL-SQL and T-SQL. All data can move happily from any client to any server in XML documents. What a relief that would be-no more compatibility issues. It’s definitely something to look forward to.