I worry that we may have created a monster.
The fact that you can now submit an XML document to SQL Server and it will break it apart for you, storing the parts into tables… it’s a pretty compelling idea. However, it also ties the persistence mechanism (SQL) to the communication mechanism (the XML document).
As an Architect, I spend my life trying to SEPERATE these two things, and then we introduce a technology that does this by its very nature. In fact, it is not all that easy to seperate them even if you really really really really want to.
Net effect: in a distributed system (with one central data store and N child systems that feed it), it is now easy to justify coupling the databases together by placing the same table into both the central system and the feeder systems, and just use SQL XML to both generate and consume the transmission document. Except that now, any change to the center has to be made to the children… even if the change doesn’t pertain to them.
This kind of coupling is bad. It violates the loose couping that SOA is engineered to provide.
Maybe there is a way to do this better. I’ve got some studying to do…
2 thoughts on “Is SQL XML a bad idea?”
i don’t think XML is transient while SQL is persistent as you seem to imply. The tight coupling is of a misuse of the feature.
My reasons are at my blog
<a href = "http://blog.theintellect.net/?p=28">
I like the fact that you can use XML to pass an array of values as a parameter to a stored proc. That’s useful. Other than something like that, I’m not that excited about it.