Yukon and the CLR

Driving home the other day I was thinking about various snippets of recent conversation over Yukon. One underlying theme is the question: Will developers go crazy with the CLR integration and hang themselves? String and array manipulation will be much easier, but the ability to throw blocking I/O statements into stored procedures is a sobering thought.

I started to do some googling to see what has turned up in the other database circles where JVM hosting has been around for a few years. It appears there are not too many complaints, and hardly any “best practice” documents to address performance related problems when mixing SQL and Java in the database.

I don’t think this sets a precedence, however. The J2EE camp often avoids stored procedures because they don't port to other platforms easily. In contrast, Microsoft has long advocated the use of stored procedures as good practice for performance and security, and as a layer of abstraction. Also, (and this section is based on my experience and may bear no relation to reality), the J2EE teams are generally bigger and have a dedicated DBA who keeps procedural thinkers from mucking up the prize jewel. At some companies the DBAs even carry small taser pistols so they can incapacitate developers who start tinkering in SQL code.

In any case, it should be interesting to see what turns up in the forums and message boards when Yukon goes live. You always have the people who say “Doc, it hurts when I do this”. Answer: “Then stop doing that!”.