...and master of none

In my last post , I demonstrated how to shape and bend XML from your existing tables in SQL Server. In this post I am going to go the other direction and shred the xml directly into SQL tables with a desired structure. I will also create a parent-child relationship between entities where no keys previously existed in the xml. This approach uses the older OPENXML mechanisms and is distinct from the value() and node() methods introduced later. I believe this approach to be superior and easier to construct than that demonstrated by Adam Machanic . I'm assuming here that you've loaded the xml into the @xmlDocument variable (as in my previous example) You need a document handle (@XmlDocumentHandle). As long as this handle remains open, the id's returned for each node do not change. Use the OPENXML function with the @XmlDocumentHandle and create an XPath query that finds the data for the you want. The value of 9 means to map attributes to your defined table, and handles r

The XML functionality of SQL Server is vast, however, the best subset of that functionality that I've found may be demonstrated in the following example: Unfortunately, the example result is listed before the code. Join all the desired tables together Set the desired root element Set the path to an empty string to avoid an extra XML element at the root of each resulting row Provide an XPATH name with attributes for each of the desired columns (select * doesn't work well) Keep all the selected columns together by XPATH name or you'll split your xml attributes See my next blog entry for my best way to shred the xml

SQL Server 2016 has (finally) a built-in string split function: STRING_SPLIT ( string , separator ) That is great, however, if you are using an earlier version, many people end up writing something that loops through the string and wherever the separator shows up, the substring is copied to a table, which is returned later. Here's an alternative... replace the separator with XML element tags and then use the built-in XML functionality to return the delimited elements. In theory, this may be slower than a tight string loop, but in practice, the XML libraries are extremely efficient, and the REPLACE function is also highly optimized. It certainly takes less code than the other approach.

Continuous Integration  is a really good idea, especially when you are working with a team of developers. There are lots of tools out there that can help your team build better quality into your application. TeamCity by JetBrains is one such tool that has been around for awhile; specifically, it is the one that my company uses. Visual Studio has Database Projects   SQL Server Data Tools  to address some of the inconsistencies that developers face when using a database as a storage layer; Things like version control and consistent deployment. It also includes SQL unit tests , which fills a huge gap if any  of your logic is in the database. Many organizations moved away from logic in the database years ago because it was tricky (at best) to verify logic on the data tier, of course, they were also making changes directly to the database itself... but I digress. If you are using SQL Server Data Tools, and run your unit tests locally, it is a joy to behold. Your database is automatical