An XML Resolution

One of my New Year's resolutions is to finally learn enough about XML to ensure that I can be "expert" in my advice about and use of many of the new XML-related features that are part of SQL Server 2005.

I've been doing database work for more than 15 years and I can still remember the heated debates about whether it was wise or insane to use NULL. Today, it's even more fun to throw together a few database experts who hold opposing views about the use of XML at the database schema and engine level. In fact, my editorial this week was sparked by some internal email threads that I was monitoring within my company.

When SQL Server 2000 first shipped, there was tremendous hype about when and how developers should use the native XML features that shipped with the product and were later extended as part of SQLXML. I didn't know XML at all and was concerned that I would be weak in SQL Server architectural and implementation issues related to XML. Fortunately, most people quickly came to the realization that the SQL Server 2000 implementation of XML simply wasn't ready for prime time because of major performance inefficiencies and a lack of features. Few people leveraged the engine-side features so, I was able to skate along without really needing to learn XML.

Alas, the native XML capabilities of SQL Server 2005 are good enough that all SQL Server DBAs and architects will need to be conversant in SQLXML related issues to ensure that they can help choose the best tool for the job; which brings me back to the recent email threads I was monitoring and how fun it can be to have SQL Server folks argue the relative pros and cons of using XML at the engine level.

I'm familiar with most of the arguments for and against XML and could probably make a case for XML being the best thing since sliced bread or the downfall of civilization as we know it, depending on what sort of mood I was in and how much I wanted to annoy the people I was debating. I don't have space in this week's editorial to fully explore the good, the bad, and the ugly associated with the use of XML within SQL Server, but in accordance with the New Year's resolution mentioned above, I promise to write more about this topic over the coming months.

For now, I'd simply like to share some sentiments expressed by SQL Server Magazine contributing editor and Solid Quality Learning Mentor Itzik Ben-Gan. He acknowledges the dangers of XML, but asserts, "That's true for any tool. Sure, XML can be more dangerous than other tools, but it can have great value if used wisely. Do you think that humanity could cope without matches and knives? Neither is something I'd give kids to play with, but in the hands of adults who know how to use them and would use them responsibly, they have great value. XML is similar to the CLR, cursors, dynamic execution of SQL, and the use of temporary tables. It's simply another tool."

Regular readers of SQL Server Magazine have known for years that Itzik is one of the most knowledgeable T-SQL experts in the world; and he's hit the nail right on the head in this case. The power--or danger--of any tool is ultimately defined by the skill and judgment of the person who wields the tool. It sure can be fun to debate the pros and cons of XML with people who hold strong opinions, and I'm sure I'll have some fun with that over the next few months in this space. But instead of focusing on the debate, I'll be more concerned with becoming skilled in the proper and judicious use of XML within SQL Server 2005 so that I can wield this new tool wisely. Happy New Year!

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.