Who Needs ORM, I've got SQL 2005

One of the coolest features of SQL 2005 is the XML support. With the recent enhancements to the FOR XML option, you can really get a lot of mileage out of SQL. A common task in a lot of applications involves retrieving an item with many children. Due to the way a lot of systems are built, this usually ends up resulting in a lot of extra queries. For example, suppose I have a customer entity like so:

public class Customer
{
  public int CustomerID;
  public string Name;
  public string State;

  public Collection<HistoryItem> History;
}

When I want to get a list of customers in a certain state, along with their histories, I might do something like this:

SELECT * from Customer where State = 'CA'

Then for each customer returned:

SELECT * from CustomerHistory where Customer = @CustomerID

The, for each of the result sets that is returned, you need to write code to take the info out of the data reader or data table and place it in your objects. As more customers are returned, the number of addition queries I need to make starts skyrocketing. The problem only gets worse as the number of levels deep increases. With SQL 2005's great XML path support, there is a really sweet thing you can do to get rid of all those extra queries and all that extra code.

SELECT CustomerID as "@CustomerID", Name as "@Name", State as "@State",
  (SELECT CustomerHistoryID as "@CustomerHistoryID", SomeOtherField as "@SomeOtherField" from CustomerHistory Where CustomerHistory.CustomerID = Customer.CustomerID FOR XML Path('HistoryItem'), TYPE ) as "History"
 from Customer FOR XML Path('Customer'), Root ('Customers'), Type

This ends up returning something like so:

<Customers>
  <Customer CustomerID="123" Name="Jesse Ezell" State="CA">
    <History>
       <HistoryItem CustomerHistoryID="456" SomeOtherField="Blah" />
       ...  
    </History>
  </Customer>
...
</Customers>

Here's where the magic comes in. Now, you've squished all those queries into a single command, and, if you execute your command with ExecuteXmlReader, you can pass the XmlReader straight to an XML serializer and return your object graph without having to write all that tedious get / set nonsense.

25 Comments

  • All of you bits of code and stored procedures who will actually make sense to programmers months from now and are maintainable, please step forward.

    Not so fast, SELECT FOR XML...

  • I've used this on (almost) every enterprise-level application I've worked on, and the benefits are too numerous to count. Less network traffic (single trip across the wire), structured return data, etc. I love using this method (and it has saved my skin MANY times). Good tip indeed...but given the usual "heated" ORM discussions that are out there, I usually keep quiet about this one. LoL...

  • You make it sound like not using FOR XML will be slower. Have you actually tried to compare the speed result of both approach uses a realistic data set?

    I'd also be curious to see each approach side by side.

    I have a feeling the non-XML way will be (a) faster and (b) cleaner.

  • Keep in mind, you don't have to use Xml serializers, you can also get an Xml reader straight from the SqlXml object and write code to populate your objects if you need the better performance. I haven't run a significant amount of comparisons between the perf of the two, but in the cases where I have returned XML results to combine multiple queries into one, I have seen significant performance boosts.

  • Hi, this sure looks nice, but do you use this only in the case where you need read only objects?

    If not, how would you go about persisting any data back to the database if there are any Updates/Inserts/Deletes??

  • > The, for each of the result sets that is returned, you
    > need to write code to take the info out of the data
    > reader or data table and place it in your objects.

    It only requies 2 roundtrips + 1 sort + 1 binary search to read master/details and put them into an object structure. A rather trivial excersize for .NET libraries.

    As for using XML for transfering data -- it looks cool but it's a bad idea. XML is bloated and expensive to parse (escaping, text-to-binary conversions, some other stuff) not to mention some specific issues, like coding nulls for value types.

  • I am currently using SQLXML and serializers in a transactional database for production use.

    I have been able to process millions of records in a no time at all. I also use CTE that also allows me to put data in memory instead of creating temp tables.

    With XML as input parameters on all my stored procs and return for XML queries my site is just as fast as any other yet, I do not have the head ache of bloated code.

    As I remember, to get an xml doc to open and parse the objects ment to load an huge amount of node dictionaries into memory and then calling methods to get values.

    With the serializer, I just deserialize the dbo return and presto the memory stream becomes an object of Type and my class is complete.

    I have even incorperated serializable objects in the form of web controls to render based on what is setup in the database. Fully function Object Oriented classes with serializable properties....

    It is very quick, using memory streams both on the components and in SQL.

  • I haven't run a significant amount of comparisons between the perf of the two, but in the cases where I have returned XML results to combine multiple queries into one, I have seen significant performance boosts.

  • You got 2005 but I need 2011 version of this one if any. I hope that you will post for some latest updates about this one. Many people would be happy for you if you gonna do it. Hope to see soon!

  • I found just the information I already searched everywhere and just couldn't find. What a perfect site. Like this website your website is one of my new favs.I like this website shown and it has given me some sort of desire to have success for some reason, so thanks.

  • HAHA! I am not a pro here but I would like to know more on this. I do want to get a basic instruction on this though.

  • I also would like to get more information about SQL 2005 for my self-education, thanks a lot in advance.

  • Pretty section of content. I just stumbled upon your site and in accession capital to assert that I acquire in fact enjoyed account your blog posts. Anyway I will be subscribing to your feeds and even I achievement you access consistently rapidly.

  • graet site. Keep doing

  • Thanks for shareing! I agree with you. The artical improve me so much! I will come here frequently.

  • Perhaps we need more updates about this. This post is four years ago and I am looking forward to see more fresher updates. Keep up the good work.

  • Yes there should realize the reader to RSS my feed to RSS commentary, quite simply

  • Excellent post.The post is written in very a good manner and it entails many useful information for me. I am happy to find your distinguished way of writing the post. Now you make it easy for me to understand and implement the concept.

  • As I remember, to get an xml doc to open and parse the objects ment to load an huge amount of node dictionaries into memory and then calling methods to get values.

    With the serializer, I just deserialize the dbo return and presto the memory stream becomes an object of Type and my class is complete.

    I have even incorperated serializable objects in the form of web controls to render based on what is setup in the database. Fully function Object Oriented classes with serializable properties....

    It is very quick, using memory streams both on the components and in SQL.

  • I found just the information I already searched everywhere and just couldn't find. What a perfect site. Like this website your website is one of my new favs.I like this website shown and it has given me some sort of desire to have success for some reason, so thanks.

  • I have found the XML support to really be a life saver! It's easier to export and import data between different sources and non Microsoft based software.

  • wI6b5l A round of applause for your blog.Thanks Again. Much obliged.

  • w3FQyO Thanks for the blog post.Really looking forward to read more.

  • obviously like your web site but you need to check the spelling
    on several of your posts. Many of them are rife with spelling problems and
    I find it very troublesome to inform the reality
    on the other hand I'll surely come back again.

  • Thanks for any other informative website. Where else may I am
    getting that type of info written in such an ideal method?
    I have a project that I am simply now running on,
    and I've been on the look out for such info.

Comments have been disabled for this content.