17.06.2013 Views

Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

The downside to using AUTO is that the resulting XML data model ends up being slightly more complex.<br />

The upside is that the data is more explicitly broken up into a hierarchical model. This makes life easier<br />

when the elements are more significant breaking points — such as where you have a doubly sorted<br />

report (for example, Order sorted within Customer).<br />

EXPLICIT<br />

The word “explicit” is an interesting choice for this option — it loosely describes the kind of language<br />

you’re likely to use while trying to create your query. The EXPLICIT option takes much more effort to<br />

prepare, but it also rewards that effort with very fine granularity of control over what’s an element and<br />

what’s an attribute, as well as what elements are nested in what other elements. EXPLICIT enables you<br />

to define each level of the hierarchy and how each level is going to look. In order to define the hierarchy,<br />

you create what is internally called the universal table. The universal table is, in many respects, just like<br />

any other result set you might produce in <strong>SQL</strong> <strong>Server</strong>. It is usually produced by making use of UNION<br />

statements to piece it together one level at a time, but you could, for example, build much of the data in<br />

a UDF and then make a SELECT against that to produce the final XML. The big difference between the<br />

universal table and a more traditional result set is that you must provide sufficient metadata right within<br />

your result set such that <strong>SQL</strong> <strong>Server</strong> can then transform that result set into an XML document in the<br />

schema you desire.<br />

What do I mean by “sufficient metadata”? Well, to give you an idea of just how complex this can be, let’s<br />

look at a real universal table:<br />

Tag Parent Customer!1!<br />

CustomerID<br />

Customer!1!<br />

CompanyName<br />

1 NULL ALFKI Alfreds<br />

Futterkiste<br />

2 1 ALFKI Alfreds<br />

Futterkiste<br />

2 1 ALFKI Alfreds<br />

Futterkiste<br />

2 1 ALFKI Alfreds<br />

Futterkiste<br />

2 1 ALFKI Alfreds<br />

Futterkiste<br />

2 1 ALFKI Alfreds<br />

Futterkiste<br />

2 1 ALFKI Alfreds<br />

Futterkiste<br />

2 1 ALFKI Alfreds<br />

Futterkiste<br />

Chapter 16: A Brief XML Primer<br />

Order!2!<br />

OrderID<br />

NULL NULL<br />

Order!2!OrderDate<br />

10643 1997-08-25<br />

00:00:00.000<br />

10692 1997-10-03<br />

00:00:00.000<br />

10702 1997-10-13<br />

00:00:00.000<br />

10835 1998-01-15<br />

00:00:00.000<br />

10952 1998-03-16<br />

00:00:00.000<br />

11011 1998-04-09<br />

00:00:00.000<br />

11078 1999-05-01<br />

00:00:00.000<br />

Continued<br />

503

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!