This editorial was originally published on Jan 19, 2015. It is being republished as Steve is traveling.

When SQL 2005 was first introduced, SQL CLR was featured by the Microsoft marketing people as the 'killer' new feature. There was rash talk of being able to write stored procedures in Visual Basic. Cynical grey-beards shook their heads in doubt, but elsewhere there was excitable whisperings about of the death of the database developer. It didn't happen.

It is an unusual characteristic of Microsoft's server division that even their technological turkeys look beautiful, and taste delicious. There was nothing wrong with SQL CLR, just as there was nothing wrong with Notification Services. SQL CLR works fine, and it is perfect for specific uses, but the concept of it being a generic solution is addled. We database developers would, of course, like easy access to all the .NET delights, such as the excellent Regex library, but we don't want a Do-It-Yourself kit to achieve this. We want something that is part of the product yet obviously separate from the standard SQL, like the spatial types and methods, and preferably something maintained by Microsoft.

If, for example, we need something as simple as regex searches, we have to craft our own CLR library within Visual Studio. Within the IT department this will be a bunch of code, put in source control, and part of the deployment process. It comes up on everyone's radar screen. It will need to be checked on every deployment for any security, stability or performance issues. Ops staff will likely take a view that they need to be able to support this long after the developers have gone, but they have no C# or CLR skills to do so. Suddenly, when placed in the context of the entire database lifecycle, it all starts looking expensive and time-consuming. Not even the developers like it because it isn't a standard implementation that they can use in other database work.

Had the product been used by Microsoft to introduce more standard, maintained, extensions like the Spatial data, providing a shrink-wrapped specialized package for string searching, aggregation and manipulation, for example, or JSON handling, then there would been more enthusiasm. Instead, it was issued limply as yet another development kit for Visual Studio, with 'Boffins Only' metaphorically stamped on the metaphorical box. The result was predictable.

Phil Factor.

Join the debate, and respond to today's editorial on the forums

The maxdop setting configures the maximum number of logical processor cores that a query can use if it goes parallel.

It is possible for a parallel query to use more worker threads than cores. In some cases, this may be a significant amount more! You can learn more about this in a classic blog post written by Microsoft’s Bob Dorr: click here

» Discuss this question and answer on the forums