Visual Studio 2005 & Enterprise Library June 2005

After trying unsuccessfully to get Enterprise Library June 2005 to work in my .Net 2.0 application I discovered this great article by Michael Schmitt on the codeproject website. Prior to running up an app in VSTS 2005 I had naively believed Ent Lib June 05 was compatible with .Net 2.0. Michael's article quickly allowed me to keep me going. As an aside I have downloaded the Nov CTP release of Ent Lib 2.0 which is available on the patterns and practices website on gotdotnet. As I am working on a commercial project for a client I will stick with the stable June 2005 release rather than place my unsuspecting client on the bleeding edge.

Holidays in Fiji

Bella and I recently returned from a well earned break in Fiji. We had an amazing time and I would recommend it to anyone who enjoys the sun, sand and water with a heap of friendly people thrown in! I have included this photo of a sunset panorama I stitched from the view from our resort villa. It was great chilling out most afternoons having a wee drink while the sun went down.
After that sort of relaxation, I feel like I have enough charge in the batteries to tackle the new technical stack from our friends at MS. Here goes!

SQL 2005, XML, XPath and Performance

I have been playing with the XML querying in SQL Server 2005 and have to say that this is nice to have what Oracle has had for a number of years now. The performance penalties associated with querying XML columns directly has presented me with a bit of a conundrum in terms of performance. Accepting that indexes can be applied to XML columns to improve query performance there still would be a significant penalty associated with querying node values within the XML column data. As it stands I believe common sense should prevail. If your application can tolerate the performance hits then don't worry about it. If perfromance is a prevalent issue the mitigating steps will need to be taken.

One suggested alternative I have read is to promote the node values into a column of not XML data type, but a data type that supports faster relational DB queries. Interestingly you would have to do this during the database design phase of development with dual updates from update code in an application or SQL. This means having a relatively known and stable XML structure. Another option is to perform a straight forward dynamic query at run time within the SQL engine i.e. retrieve the node values from the XML column and place into a column within a temporary table (or the like) for more complex data queries to be performed. Maybe there is a better approach but I am yet to find it!

As an aside when an index is created on an XML column (CREATE PRIMARY XML INDEX idx_Index ON Table(Column) ,apparently this creates a node table to improve searching of XML structures. Obviously if it doesn't have to build on in memory structure for each query then this would be faster than a non indexed XML column. I need to investigate what happens to newly created XML data that has more nodes. Does the index update with every insert? If it doesn't then loading an XML schema (XSD) would be recommended in addition to regular updates of the index.