Readers who live in the United States are probably familiar with a long-running series of Capital One Services commercials in which a horde of barbarians gleefully prepare to pillage an unsuspecting consumer’s finances. But then, the consumer pulls out a Capital One card. The barbarians are defeated and the consumer goes on with life, blissfully unaware of his or her close call with the apocalypse. Lately, that commercial makes me think of the SQLCLR.
Years before the release of SQL Server 2005, the general consensus among SQL Server experts and pundits alike was that the SQLCLR had the potential to rain doom and destruction of epic proportions upon the unsuspecting heads of the world’s DBAs and their carefully maintained relational databases. Presumably, the sanctity of the world’s SQL Server databases had long been protected by these DBAs in shining armor who successfully kept the hordes of barbarian developers from overrunning their relational database strongholds. Needless to say, any self-respecting DBA knows that a barbarian developer must never be allowed to run amok within the core relational engine. Anarchy would surely result. Sure, a few moderately enlightened developers might be able to figure out how to write stored procedures, but the saintly DBA would always have the ability to fix code that didn’t meet the company’s high performance standards.
Egads! Might the SQLCLR provide those devious barbarian developers an effective way to ford our relational moats, destroying the peace and tranquility of our relational villages and subjecting our kinfolk to a life of servitude under the draconian rule of illiterates unable to chant the key tenets of relational theory?
Fast forward. It’s almost a year since the release of SQL Server 2005. Harmony still exists. In fact, I don’t see many customers using the SQLCLR at all. Perhaps those barbarian developers are more cunning than the noble DBA gave them credit for? Perhaps they’re biding their time, hoping that the DBA will grow complacent and say, “Sure, we can turn on the SQLCLR.”
Okay, arguably, the danger is real. The SQLCLR does have the potential to be used poorly. But I’m still a bit surprised by the low number of customers who seem to be dabbling with it. We had a SQL Server Magazine editor’s conference call the other day, and I raised the topic to make sure I wasn’t all wet in wondering about this apparent slow adoption. Most of my colleagues confirmed my observation, and most of us thought that the fact that the SQLCLR doesn’t seem be getting much use might be a good thing. But in some circumstances, the SQLCLR would be a wonderful tool. (No, I’m not going to tell you what it’s good for this week. Writing a weekly editorial is pretty hard, and I need to save something interesting to write about in upcoming weeks.)
I’m glad the SQLCLR isn’t being used poorly, but I wonder why it’s not being used for good. Perhaps you, our faithful readers, know the answer. Please share your stories about why you are or aren’t using the SQLCLR and your opinions about why it doesn’t seem to be getting more use in the SQL community. And yes, your responses will give me interesting fodder for yet another weekly editorial, so I’m coming out way ahead in my writing schedule this week!
Send your thoughts to me at [email protected].
