Thank you for the correction regarding the
The customers we are running into have multiple problems. Sure, they have data that needs to be integrated into their relational model. And we have the tools to help do that. They also need to integrate with SAP, i2, Ariba, Essbase or Hyperion for analysis, old IBM mainframes, etc. They tried EAI, but EAI was too loosely coupled and they needed a record of the data flowing back and forth. Our DB tends to be used as a middle-tier XML data “hub” that handles pulling data in from many different sources and transforming it out to many different sources. None of this data is “Shakespeare”. You ought to see some of the data models we’ve run across in insurance, financial services, telco, retail, and other sectors that are making use of XML to solve this aggregation/integration problem. You’ve got combinations of structured, semi-structured, and unstructured data from both internal and partner systems that have to be combined into a common data model. The first thing they tried was to normalize it (or even leave it slightly de-normalized) and put it into a relational database. They tried and they failed. It was too painful and the system could not keep up with the volume of this data that they were seeing. These are Global 2000 companies that are not seeing this as a special exception, but as a rule.
Our philosophy is if you can make it fit a relational schema, the schema of the incoming XML does not evolve or change very often, and you’ve made it work and you’re comfortable with it, save for our caching and XSLT capabilities, we do not bring much value. If you can make it fit relational through mapping and you’re happy with the result, stick with it. But, what we’ve found in our customers, prospects, etc. (which are numerous) is that they’ve tried and they couldn’t make it work.
From rumors I’ve heard, Microsoft has realized some of these limitations and is working on devising ways in SQL Server to make most of these arguments invalid. I think this is great because it validates the usefulness of XML as a common data model to solve these real business problems.
Dear Chris. While I don't dispute that there are situations where a native XML store is better than the mapping, let me address some of your points below.
I think it is important to note that XML-enabled relational databases have some specific scenarios in mind (integrating relational data/schemata with XML in a bi-directional way) that do not work that well for storing "document-centric" XML. Thus, use the tools that fit the task at hand.
[Michael Rys] <snip/>
The update facility of SQL Server is released and fully supported (and not beta). It is shiped as a web release via msdn.microsoft.com/xml and /sqlserver.
If you need to integrate with your existing relational data model, then the story of course looks different.
This is a fairly vague statement. You need to do the mapping once and there are tools available (at least for the SQL Server annotated schema approach) that provide you with a simple to use visual interface. Can you provide more information why and when mappings fail or become immensely complex in the context of data-centric XML documents (and not Shakespeare)?