XPath in T-SQL?

I started reading the.NET magazine article about Yukon and this weird remark started me thinking:

"First, Yukon includes XML as a native SQL Server datatype. The capability to store and query XML documents within a relational database will become increasingly important as your migration to XML progresses. For example, you might be required to archive third-party SOAP request and response messages for nonrepudiation or auditing purposes. Support for XPath and XQuery extensions to T-SQL will probably eliminate most organizations' need to invest in dedicated XML data stores. "

XPath in T-SQL? Don't get me wrong, perhaps there is a way that this is useful, but this sounds like a clash of paradigms to me. XPath is a pattern-matching language, which behaves like a functional language. T-SQL on the other hand is a set-based language. To me these two paradigms are not mixable, like it is hard to mix procedural code with XPath code in an XSL sheet, just because they are two different paradigms: functional (XPath) and procedural (the script).

It's already not that good that T-SQL supports all kinds of middle/gui tier mumbo jumbo like string formatting, while constructions etc, but alas, it's there, you don't have to use these statements, however mixing T-SQL with XPath, as a pillar for the suport for the marketing hit 'XML', I think they've gone a bridge too far.

3 Comments

  • I have to disagree - while I'm very worried about CLR code showing up in SP's, I think pattern matching is a natural extension of SQL and a welcome extension. Like SQL, XPath is used to define "what" I want (declarative), rather than "how" to do what I want (procedural). The WHERE clause is used to filter records, and becomes much more powerful if it can match on addresses with apartment numbers, text fields containing URL's, etc. I very much agree that procedural constructs in SP's is a bad paradigm mix, but SQL has long needed some improved pattern matching abilities.

  • I have to disagree as well. XPath comes because of the XML support in Yukon. Apart from that it doesn't make a ton of sense, however, you definately don't want to query xml data with T-SQL... because T-SQL is designed for RDBMS systems, not xml.

  • If they use it solely to add new predicate clauses to the WHERE clause, indeed to filter out rows matching the single XPath clause, it is ok to me, however the usage of XML as a storage form, requires the existence of XSL and XPath to work with the XML, and I do not see how these two can be mixed with T-SQL.

Comments have been disabled for this content.