Why would I ever choose to store and manipulate XML in a relational database?

Question

Modern RDBMS\'s have support for XML column types and functionality for dealing with XML in stored procedures. Historically I would always have mapped hierarchical data (whe

Answer 1

If you don't see the need then don't change!

Sometimes you have to persist data that does not have a known structure, or its structure is very volatile. In those cases, instead of creating a table, just save the XML into your existing table

Answer 2

The only reason I would ever use it again is when for extensibility & flexibility.

The overhead of xml (xpath) and maintenance (namespaces) are really not worth the hassle if you can avoid it. We have previously stored large amounts of data in xml and used scalar functions to retrieve it, but it is too slow and causes immense headaches is the xml structure or namespace changes.

But the flexibility is fantastic. You can add new properties whenever you want, you can have project/client/job specific data in there which doesn't require proper columns. The XML does not have to be in a static structure - you simply need a factory which can spawn instances to deal with the different XML (which would need to be related to a project/client/job).

When adding a new table to an existing system, especially one that has a lot of existing data and can't easily be modified, I will add an XML column. In the future if I ever need to add another column to that table, I can simply utilise the XML column rather than being frustrated and having to do a lot of rework.

In summary, you don't start out by putting essential properties in XML. But you should add XML when you know that your table might need to be extended, precisely because it gives you the option of extending.

Answer 3

Flexibility is one reason.

If the structure of your data can vary, then you can still keep a common RDBMS table, along with the queries, etc. that gor after it with the somewhat variably structured data.

If you need to add a field at some point, you can do so without changing your RDMS table structure, and thus not break everyone else's queries.

Answer 4

I have a good real-life example. One of my clients receives an XML file from their suppliers very often with some important data. It is deeply nested. They need to compare it with the previous XML file to see what has changed. Without XML support in database, I had to build a tool that iterates through XML nodes and looks for matches in the tables of relational database. I could use some XML-XML comparison tool, but some of the checks relate to some other data that did not come from XML file and I need to join all that together. Ok, all of this is not that big deal, but still - with XML databases you get that functionality out-of-the-box.

Answer 5

I use the XML column type to stash a copy of all business-critical messages we receive from a third-party service. It's very handy for a few reasons.

1) In case of data corruption, we can back-trace to see what data came in when, and in what format.
2) Future development work on systems can be based on real data from the log table - just deserialise and use the data as if it came from a call to the 3p service
3) Makes sure the infrasructure guys are busy allocating disk space to the DB server. ;)

Answer 6

You can store user generated XML in there.

If a website like stackoverflow used some sort of XML markup instead of mark down you could store the question/answers as XML in the database. You might find yourself trying to parse this user generated XML looking for proprietary tags.