SQL Server 2005

[Ronald Bourret]

Frank Cohen wrote:

> Where I have a problem is with complex XML documents like those  created 
> using UBL for ebXML solutions. When a service or application  receives 
> an XML document containing hundreds-to-thousands of  elements, lots of 
> nesting, and many different schema versions then I  think its time to 
> look at adding an XML database to the datacenter.

This is an interesting problem.

One assumes that the business applications involved are already based on 
relational databases, so what happens when you stop supplying those 
applications with their data? Do you rewrite the applications to use 
native XML technology? Build a relational wrapper over the data, in 
effect shredding it at the query level instead of the storage level? Or 
are these simply brand new applications built from the ground up?

(The one argument you've made so far that would strongly push me into 
the native camp is many schema versions, which seem to be more painful 
in the relational world than the native XML world, although still 
painful nonetheless.)

Out of curiousity, what is the nature of the documents? In particular, 
how deeply are they nested (excluding wrapper elements that wouldn't map 
to relational structures)? Do they contain repeating high-level 
structures, such as a document containing multiple sales orders, which 
would be easily split into many smaller documents? And how much of the 
data simply provides context and doesn't need to be stored in the 
database? For example, a sales order would probably include customer 
information, but there's a good bet this is already in the database.

-- Ron