为什么要在SQL Server中使用.net程序集？

Question

我正在研究我正在管理的系统中的一些预先存在的代码，我有一个问题：

如果您在该程序集中所做的只是插入/更新/删除，为什么要在SQL Server中使用.net程序集。

我在程序集.Net代码中看到的一些负面因素是，每次调用每个函数时，每个函数都会创建自己的与SQL Server的连接，并且这些函数中使用的insert / update / delete命令在.Net中被硬编码代码。

我错过了什么吗？这种方法比使用存储过程更快吗？

Answer 1

我不这么认为它比SQL快，也不应该比较。因为托管存储过程不是SQL存储过程的替代方法。只有当我们想要使用某些.net api时，才会使用托管代码，即.Net dll作为存储过程。我的意思是，如果我想在从/向数据库检索/插入图像时进行一些图像处理，这可以使用.Net然后我将创建一个托管存储过程。

Answer 2

你不会。

TL; DR版本：我不会将CLR用于简单的更新/插入/删除/选择操作。

有时人们喜欢使用新的闪亮的东西，因为它们是新的和有光泽的，或者因为他们有一些误解，认为它们在所有情况下都更好。

以MERGE为例 - 人们喜欢这种不直观且难以学习的语法，因为它是新的，并且他们相信原子性和对竞争条件的保护，而这些条件在默认情况下是无法保证的（但他们假设是承诺），他们也忽略了大量未解决的错误（见this article）。

使用CLR，人们倾向于概括为“哦，它已编译，所以它必须比T-SQL更快，这被解释。” CLR有一些非常好的用例，其中 是比T-SQL更好的选择（想想RegEx，可能是最老的用例，它没有本机T-SQL实现（后台{{ 3}}），或者我最喜欢的一个，分裂字符串，如果你不能使用TVP - 背景here，here和here）。不幸的是，CLR的互操作开销使其成为简单数据检索和数据操作任务的不良选择。 here表明FOR XML PATH在特定用例方面优于CLR。对于一般数据操作和数据检索操作（通常称为CRUD），它们不使用T-SQL中不能直接使用的功能，或者不需要大量字符串操作，这些操作性能极差，我不会使用CLR 。即使在这些情况下，我也会使用CLR函数或过程来完成所需的繁重工作，但仍然使用T-SQL执行基本CRUD操作。

其他一些可能有用的链接：

This blog post

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