SQL Server 2012 : XML and the Relational Database - Querying XML Data Using XQuery (part 2) - SQL Server XQuery in Action, XML DML

Having XML in the database is almost useless unless you can query the elements and attributes of the XML data natively. XQuery becomes very useful when you use it to search XML based on the values of a particular element or attribute. The xml.exist method accepts an XQuery query as input and returns 0, 1, or NULL, depending on the result of the query: 0 is returned if no elements match, 1 is returned if there is a match, and NULL is returned if there is no data to query on. For example, Example 5 shows how to test whether a particular node exists within an XML document.

DECLARE @SomeData xml = '
<classes>
         <class name="SQL Server Index"/>
         <class name="SQL Precon"/>
</classes>'

SELECT
 @SomeData.exist('/classes') AS HasClasses,
 @SomeData.exist('/dogs') AS HasDogs

This query produces the following output:

HasClasses HasDogs
---------- -------
1          0

You will most likely use the return value of xml.exist (0, 1, or NULL) as part of a WHERE clause. This lets you run a T-SQL query and restrict the query on a value of a particular XML element. For example, here is an XQuery expression that finds every <class> element beneath <classes> with a name attribute containing the phrase “SQL Server”:

/classes/class/@name[contains(., "SQL Server ")]

Example 6 shows how you put this expression to work.

SELECT * FROM Speaker
 WHERE
  ClassesXML.exist('/classes/class/@name[contains(., "SQL Server")]') = 1

The results look like this:

SpeakerId  SpeakerName  Country  ClassesXML
---------  -----------  -------  ----------
1          Jeff Hay     USA      <classes speakerBio="Jeff has solid security...
2          Holly Holt   Canada   <classes speakerBio="Holly is a Canadian-bor...

Jeff and Holly (but not Ted) each give one or more SQL Server classes. The XML returned in these results look like this for Jeff:

<classes speakerBio="Jeff has solid security experience based on years of hacking">
  <class name="Writing Secure Code for ASP .NET" />
  <class name="Using XQuery to Manipulate XML Data in SQL Server 2012" />
  <class name="SQL Server and Oracle Working Together" />
  <class name="Protecting against SQL Injection Attacks" />
</classes>

Example 7 shows a query similar to the previous one. This version demonstrates how to seamlessly integrate XQuery with ordinary filtering of relational columns, by simply building out the WHERE clause to further restrict by Country for USA only.

SELECT * FROM Speaker
 WHERE
  ClassesXML.exist('/classes/class/@name[contains(., "SQL Server")]') = 1
  AND Country = 'USA'

Executing this query returns only Jeff. SQL Server will filter out the other two rows because Ted does not have any SQL Server classes and Holly is from Canada.

The xml.value method takes an XQuery expression that resolves to a single value and returns it, cast as the SQL Server data type you specify. You can leverage this very powerful method to completely shield the internal XML representation of your data, and expose ordinary scalar values with ordinary SQL Server data types instead. Consider the query in Example 8.

.SELECT
  SpeakerName,
  Country,
  ClassesXML.value('/classes[1]/@speakerBio','varchar(max)') AS SpeakerBio,
  ClassesXML.value('count(/classes/class)', 'int') AS SessionCount
 FROM
  Speaker
 ORDER BY
  ClassesXML.value('count(/classes/class)', 'int')

From the output generated by this query, there is no indication that—behind the scenes—the source for some of the output comes from an embedded XML document, stored in an xml data type column, and then shredded with XQuery:

SpeakerName Country SpeakerBio                                               SessionCount
----------- ------- -------------------------------------------------------- ------------
Ted Bremer  USA     Ted specializes in client development                    2
Holly Holt  Canada  Holly is a Canadian-born database professional           3
Jeff Hay    USA     Jeff has solid security experience from years of hacking 4

The SpeakerName and Country columns came right out of the Speaker table. However, the SpeakerBio and SessionCount columns were each extracted from the ClassesXML column using xml.value with an XQuery expression and a SQL Server data type that the expression’s result was cast to. Because you are requesting a specific data type, the XQuery expression must resolve to a single value. That value can come from a node element’s inner text, attribute, or XQuery function, but it must be a single value. For SpeakerBio, the XQuery drills into the classes element for the speakerBio attribute, extracts its value, and casts it as a varchar(max) type. The XQuery for SessionCount invokes the count function to return the number of class elements nested beneath the classes element cast as an int. The same XQuery is used again in the ORDER BY clause, so that the results of the query themselves are sorted by a value derived from data embedded in XML content.

You can build views and TVFs over queries such as this, and create an effective abstraction layer over the way XML is stored internally in your database. This means you can alter the XSD schemas and then adjust the XQuery expressions in your views and TVFs accordingly, such that consumers remain unaffected. Indeed, you could even transparently switch from XML storage to traditional column storage and back again, without disturbing any existing clients. SQL Server thus provides extremely flexible abstraction in both directions, because you’ve seen the myriad of ways to dynamically construct and serve XML from relational column data with the various FOR XML options . This flexibility means you can choose just the right degree of XML integration in your database that best suits your needs—whether that involves persisting XML data, constructing XML data, or both.

The xml.query method accepts and executes an XQuery expression much like the xml.value method, but it always returns an xml data type result. So unlike xml.value, the XQuery expression doesn’t need to resolve to a single value, and can easily return multiple values as a subset of the source XML. But furthermore, it can transform that source XML and produce entirely different XML—even injecting values from other non-xml columns living the in same row as the xml column being queried. Example 9 demonstrates how this is achieved using FLWOR expressions and sql:column (a SQL Server XQuery extension).

SELECT
  SpeakerId,
  ClassesXML.query('
    let $c := count(/classes/class)
    let $b := data(/classes[1]/@speakerBio)
    return
      <SpeakerInfo>
        <Name>{sql:column("SpeakerName")}</Name>
        <Country>{sql:column("Country")}</Country>
       <Bio>{$b}</Bio>
        <Sessions count="{$c}">
          {
            for $s in /classes/class
            let $n := data($s/@name)
            order by $n
            return
              <Session>{$n}</Session>
          }
        </Sessions>
      </SpeakerInfo>
           ') AS SpeakerInfo
 FROM
  Speaker

The XML returned in these results looks like this for Jeff:

<SpeakerInfo>
  <Name>Jeff Hay</Name>
  <Country>USA</Country>
  <Bio>Jeff has solid security experience from years of hacking</Bio>
  <Sessions count="4">
    <Session>Protecting against SQL Injection Attacks</Session>
    <Session>SQL Server and Oracle Working Together</Session>
    <Session>Using XQuery to Manipulate XML Data in SQL Server 2012</Session>
    <Session>Writing Secure Code for ASP .NET</Session>
  </Sessions>
</SpeakerInfo>

Let’s explain the code in detail. The XQuery expression in the xml.query method on the ClassesXML column begins with a FLWOR expression. The two let statements use XPath expressions to capture the speaker’s number of classes (using the count function) and bio text (using the data function), and stores the results into the variables $c and $b respectively. Then the return statement defines the shape of the XML to be constructed, starting with the root node’s <SpeakerInfo> element. Inside the root node, the <Name> and <Country> elements are returned, with values extracted from the SpeakerName and Country columns. These are values that are not present in the XML being parsed by xml.query, but are available as ordinary columns elsewhere in the same row, and are exposed using the special sql:column SQL Server extension to XQuery.

Next, the <Sessions> element is returned with a count attribute that returns the number of class elements beneath the source XML’s classes element. Within <Sessions>, a new (nested) FLWOR expression is used to iterate the speaker’s classes and build a sequence of <Session> elements. The for statement loops through the source XML’s classes element for each nested class element and stores it into the variable $s. The let statement then uses the data function to capture the string value inside the name attribute of the class element in $s and stores it into the variable $n. The inner FLWOR expression results (that is, the sequence of elements returned by the upcoming return statement) are sorted by name using the order by statement. Finally, the return statement generates a new <Session> element. The session name is rendered as the inner text of the <Session> element. This XQuery has essentially transformed the <Classes> and <Class name=“title”> structure of the source XML to a <Sessions> and <Session>title</Session> structure.

The sql:variable function is another very powerful SQL Server extension to XQuery. With it, you can easily parameterize your XQuery expressions using ordinary T-SQL parameters. This technique is demonstrated in Example 10.

DECLARE @Category varchar(max) = 'SQL Server'

SELECT
  SpeakerName,
  Country,
  ClassesXML.query('
    <classes
      category="{sql:variable("@Category")}"
      speakerBio="{data(/classes[1]/@speakerBio)}">
      {
        for $c in /classes/class
        where $c/@name[contains(., sql:variable("@Category"))]
        return $c
      }
    </classes>') AS ClassesXML
 FROM
  Speaker
 WHERE
  ClassesXML.exist
   ('/classes/class/@name[contains(., sql:variable("@Category"))]') = 1

The results look like this:

SpeakerName  Country  ClassesXML
-----------  -------  ----------
Jeff Hay     USA      <classes category="SQL Server" speakerBio="Jeff has solid e...
Holly Holt   Canada   <classes category="SQL Server" speakerBio="Holly is a Canad...

The XML returned in these results looks like this for Jeff:

<classes category="SQL Server"
   speakerBio="Jeff has solid security experience from years of hacking">
  <class name="Using XQuery to Manipulate XML Data in SQL Server 2012" />
  <class name="SQL Server and Oracle Working Together" />
</classes>

In this example, the T-SQL @Category parameter is assigned the value SQL Server, and the sql:variable is then used in several places to reference @Category. The first reference adds a category attribute to the classes element. The second reference applies filtering against the name attribute using contains in the inner FLWOR expression’s where statement, and the last reference applies filtering at the resultset row level in the SELECT statement’s WHERE clause. Thus, only rows having SQL Server in the name of at least one class are returned in the resultset, and within those rows, only classes having SQL Server in their name are returned as elements in ClassesXML (all other non-SQL Server classes are filtered out).

Our last xml.query example demonstrates how to combine child elements into a delimited string value, as shown in Example 11.

SELECT
  SpeakerName,
  Country,
  CONVERT(varchar(max), ClassesXML.query('
    for $s in /classes/class
    let $n := data($s/@name)
    let $p := concat($n, "|")
    return $p')) AS SessionList
 FROM
  Speaker

The SessionList column produced by this query contains a single pipe-delimited string containing the names of all the classes given by the speaker:

SpeakerName Country SessionList
----------- ------- ----------------------------------------------------------------------
Jeff Hay    USA     Writing Secure Code for ASP .NET| Using XQuery to Manipulate XML Da...
Holly Holt  Canada  SQL Server Profiler| Advanced SQL Querying Techniques| SQL Server a...
Ted Bremer  USA     Smart Client Stuff| More Smart Client Stuff|

This XQuery expression in Example 11 simply iterates each class element, extracts the name attribute, and concatenates it with a pipe symbol, appending each result to build a single string. Although the elements are ultimately combined to form a single value, they are still multiple values from an XPath perspective, and so xml.value cannot be used. Instead, xml.query produces the concatenated string, and CONVERT is used to cast the result as a varchar(max) data type.

The W3C XQuery specification does not provide a way for you to modify XML data as you can modify relational table data using the INSERT, UPDATE, and DELETE keywords in T-SQL. So Microsoft has created its own XML data manipulation language, XML DML, which is included in its own XQuery implementation.

XML DML gives you three ways to manipulate the XML data of a column via the xml.modify method:

UPDATE Speaker
 SET ClassesXML.modify('
  insert
    <class name="Ranking and Windowing Functions in SQL Server" />
  into
    /classes[1]')
 WHERE SpeakerId = 1

UPDATE Speaker
 SET ClassesXML.modify('delete /classes/class[4]')
 WHERE SpeakerId = 1

UPDATE Speaker
 SET ClassesXML.modify('
  replace value of /classes[1]/class[3]/@name[1]
        with "Getting SQL Server and Oracle to Work Together"')
 WHERE SpeakerId = 1