Home/ Questions/Q 917501
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T18:13:21+00:00

(This post is soliciting personal experiences about storing XML; please share what you know.

  • 0

(This post is soliciting personal experiences about storing XML; please share what you know. 🙂 )

I am working on a service application that communicates with an external service using XML. I am planning to use SQL Server 2008 to store the XML that is received and sent to the external service. I’m exploring my options for storing the XML in the database. The three options that I have identified are:

  1. Store the XML in an XML data type column
  2. Create tables to store the various parent and child relationships represented in the XML.
  3. A hybrid of the two above approaches where the original XML is stored in an XML data type column but several fields from the XML broken out into their own columns to simplify querying and indexing.

I’m looking for any advice, based on your personal experience, with storing and retrieving XML data in SQL Server.

Some additional background: I’ve used an ‘xsd.exe’ equivalent called XsdObjectgenerator to create .net classes based on the XML schemas. When the service receives the XML file, it is deserialized into an instance of .net class. This instance is used to perform the operations of the service. My original plan was to then use option #1 above to store the XML. If I needed to update or report on the data, I would simply deserialize the db record back into one of my .net classes.

Although this approach works and makes working with the xml very simple, I have concerns that as the volume of data increases, the performance of querying XML data type records will decrease. This is why I’ve explored options 2. & 3. above.

In addition to storing the XML, the XML will be queried for use in both reports and a separate web application. The db records will be queried, sorted, filtered, grouped, summaried and possibly updated by the end users.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I guess it depends on what you want to do with your XML in your database.

    If you’re mostly only storing it, and possibly retrieving it later as a whole and sending it out again, then I’d definitely use the XML datatype – no point in shredding it into bits and pieces.

    If you however need to mostly work with the contents of the XML file, and possibly also manipulate and change that content, then it might be advisable to create tables with columns to match your XML content, and shred it when storing it, use it, and when you need to, reassemble it from the relational pieces using something like SELECT (columns) FROM dbo.Table FOR XML.....

    There is an overhead involved in shredding and reassembling – so you need to ask yourself if that’s worth doing. But there’s also an overhead involved if you need to manipulate the XML column too much.

    If you only need read-only access to a few attributes in your XML, I’ve come to appreciate the ability to wrap those into a UDF and surface it as a computed column in your table. That way, you can easily select something from your table, based on values that are stored somewhere inside your XML – quite handy! But do not overuse this approach – works fine for 2, 3 attributes – but if you need to access your XML over and over again (and most or all of it), then you might be better off shredding it into relational pieces to begin with.

    • 0