I have a reasonably complex XML document which I want to flatten down to tables in SQL Server 2005. I don’t want to have to code each field and table mapping by hand. The data is going into the staging area of a data warehouse so it doesn’t really matter that much how the tables are structured.
So far I have considered, and rejected the following…
OpenXML – it seems that I can read the xml into memory in sql using this, but then have to write a load of sql to perform all the inserts. No thanks.
XML Bulk Load – looks pretty good, but I get the impression I am expected to write an XSD which details all the relationships. Don’t see why I should have to when they are implicit in the hierarchical structure of the xml.
SqlBulkCopy – looks like I still have to write all the mapping stuff.
Having rejected all these I am thinking about rolling my own in C#, the idea seems quite simple. Read the data into an xmlReader, then walk the tree and generate the inserts. I can have a seperate action which is only run at development time to generate the schema.
Any thoughts on this?
In this case the final answer turned out to be much more simple…
By going through the details of the requirements it turns out that even thought the data is highly structured, the parts of it that we need can be represented by a single table. Therefore I can run an xslt transform against the xml to give me a set of rows and columns which go straight into a table. Via SSIS in this case.