Welcome to Office Zealot Sign in | Join | Help

SQL Server and CLR Integeration

SQL Server 2005 will support: creating triggers, stored procedures, custom data type and custom aggregates using .NET code. While this is a really cool idea it’s a non-starter. It’s my belief that .NET code will be created and called from very few applications for a number of reasons.

The first being performance.  There is just no way that the .NET Framework code will ever be as efficient as Transact SQL. 

Second is the fact that most DBAs don’t have the time or desire to become experts in VB.NET or C#. Most DBAs I deal with are already overworked keeping their databases humming. I don’t see them encouraging developers to begin adding even more work to their already full agenda.

Finally I see some architectural nightmares coming. Developers will now run out and begin adding business logic to their databases in the form of clever stored procedures and triggers. The problem with this is that it moves the business logic behind the database instead of in front of the database. This kills the ability to scale your applications in any way, shape or form. You see SQL Server does not scale out very easily (the concept of scaling out is to add more machines to distribute load), In SQL Server it is best to scale up (buy a bigger machine). Well, if your business logic is behind the data any chance of scalability goes out the window.

There is one part of this I do really like. The idea of creating your own custom data types and aggregates. You can take VB.NET or C# code and create your own datatypes that act like objects in your database. I cannot wait to create a credit card datatype, phone number datatype, SSN data type. I think aggregates has some interesting uses too.

Thoughts ?

Published Friday, October 22, 2004 11:55 AM by rod

Comments

# re: SQL Server and CLR Integeration

Wednesday, October 27, 2004 10:22 PM by Anonymous
Hey, Rod

I agree with your points - and I'll add that some DBAs will not permit SPs to be written in .NET. So they'll likely keep CLR support turned off.

Interestingly, Michael Otey wrote (latest issue of sql server mag) that CLR objects (compiled) will run faster than those written in T-SQL (interpreted).

But he concluded that T-SQL is still better for data access operations.

He sees CLR integration as valuable if you want to replace extended stored procs, or if you need to write complex math/logic operations, or tap into external system resources. But in some cases, you're back to some of the arguments you raised about things behind the database instead of in front of it.

Related, here are some good sites for info on T-SQL enhancements in Sql server 2005:

http://www.sys-con.com/story/?storyid=45543&DE=1

Kevin

# re: SQL Server and CLR Integeration

Wednesday, December 01, 2004 10:13 AM by Anonymous
I agree with this as well. From the presentations I have seen though, it looks like the .NET integration into SPs is more like a replacement to what used to be XPs (extended stored procs).
Anonymous comments are disabled