This post originated from an RSS feed registered with .NET Buzz by Steve Hebert. Original Post: CLR/SqlServer Integration editorial on SSWUG Feed Title: Steve Hebert's Development Blog Feed URL: /error.htm?aspxerrorpath=/blogs/steve.hebert/rss.aspx Feed Description: .Steve's .Blog - Including .Net, SQL Server, .Math and everything in between Latest .NET Buzz Posts Latest .NET Buzz Posts by Steve Hebert Latest Posts From Steve Hebert's Development Blog

Joe Celko has an editorial on CLR integration with Sql Server 2005 on the SSWUG site titled "CLR: Threat or Menace".

On one hand, I absolutely agree with Mr. Celko on the fact that a bad developer will bring the database to its knees.  This is regardless of the presence of the CLR.  Project planning on a Sql Server 2005 project that utilizes CLR code must be extremely aware of the people they are dedicating to that task.  I certainly agree that a bad programmer will ignore the optimizations that can be made by the set-based processing of the SQL engine and decide to muscle processing through row-based processes.  However I think this is where Joe's argument starts to go flat.  The argument starts pointing at developers as the prototypical “unwashed masses” and supports CLR exclusion by campaigning under the basic idea of “a cork for every fork.”

Here are a few points I found questionable…

• “What do the CLR languages do with NULLs?  They do not have null, so the programmers will have to catch them and make up their own rules for stored procedures or constraints.“  Note to Joe, it’s all in the Sytem.Data.SqlTypes namespace…
• “When programmers write CLR code inside the database, they will use cursors, explicitly or implicitly inside objects. Go to any SQL Newsgroup and look at the postings. The newbies confuse rows and records, columns and field, and think that tables have an ordering.”  I believe Mr. Celko is arguing that developers fail to see the set-based orientation of SQL and will inevitably misuse the tool. As I recall there was a time when SQL was viewed as a way to kill database performance by hiding the technical details from the users – just because I can do it in SQL doesn’t mean I always should.  Let’s face it, Mr. Celko’s long-running SQL coding exercises would’ve had SQL’s opponents pointing to these as reasons SQL is evil.  SQL’s early venomous detractors have largely disappeared, and I suspect CLR integration detractors will largely go the same route. 
• “No good Sql programmer would code at the level of bits and bytes.”  -  Without an understanding of how the bits and bytes operate, can you really develop more than a regurgitative understanding of how the database optimizes joins and set selection?
• “Will Johnny write a trigger or stored procedure with the functions from his favorite CLR?”  I have not heard any Microsoft type state that triggers should be written in CLR code.  This is due, in large part, to the overhead and latency of executing CLR code. 
• Mr. Celko points out the SQL/PSM role, an ANSI/ISO standard for putting procedural code into the schema. Does the world really need yet another language to solve a simple task?  A real programmer is not excited by languages, but by the problems at hand and how to solve them.  Languages are nothing more than a tool – why create more when you can utilitize tools that have a larger audience?
• Mr. Celko points out the need for a strict division between the database people and applications people and never the two shall meet. If any talent pool was more diluted by the boom cycle of the ‘90s it’s the DBA.  It’s easy to argue that most DBA’s are nothing more than operations people with over-hyped titles.