Why would you want to use a .net assembly in SQL Server?

Question

I'm researching some pre-existing code in a system I'm managing and I have a question:

Why would you want to use a .net assembly in SQL Server if all you do in that assembly is insert/update/delete.

Some negatives I see in the assembly .Net code is that each function creates its' own connection to SQL Server each time each function is called and the insert/update/delete commands used within these functions are hard coded in the .Net code.

Am I missing something? Is this approach faster than using stored procedures?

Answer 1

You wouldn't.

TL;DR version: I would not use CLR for simple update/insert/delete/select operations.

Sometimes people just like to use new shiny things because they're new and shiny, or because they have some misconception that they're better in all cases.

Take MERGE for example - people love this unintuitive and hard-to-learn syntax because it's new, and they trust things about atomicity and protection from race conditions that aren't guaranteed by default (but they assume are promised), and they also ignore that there are a ton of unresolved bugs (see this article) and several colleagues simply say not to use it at all.

With CLR, people tend to make the generalization that "oh, it's compiled, so it must be faster than T-SQL, which is interpreted." CLR has some very good use cases where it is a better option than T-SQL (think about RegEx, probably the oldest use case, which doesn't have a native T-SQL implementation (background here), or one of my favorites, splitting strings, if you can't use TVP - background here, here and here). Unfortunately, the interop overhead of CLR make it a poor choice for simple data retrieval and data manipulation tasks. This blog post shows that FOR XML PATH outperforms CLR for one specific use case. For general data manipulation and data retrieval operations (often referred to as CRUD) that don't utilize features not available directly in T-SQL, or that don't require massive string operations that are abysmal performance-wise, I would not use CLR. Even in those cases I would use CLR functions or procedures to do the heavy lifting required but still perform the base CRUD operations using T-SQL.

Some other links that might be useful reading:

• SQL Server 2008 CLR vs T-SQL: Is there an efficiency/speed difference?

• Are CLR stored procedures preferred over TSQL stored procedures in SQL 2005+?

• Performance of CLR Integration

• TSql vs. SQL CLR Performance Analysis

Answer 2

i don't think so it is faster than SQL and also not should be compared. Because Managed stored procedure are not an alternative of SQL stored procedure. Managed code i.e. .Net dll as a stored procedure will be used only when we want to use some .net api. I mean if i want to do some image processing when retrieving/inserting image from/to database which will be possible using .Net then i will create a managed stored procedure.