我正在研究我正在管理的系统中的一些预先存在的代码，我有一个问题：
如果您在 SQL Server 程序集中所做的只是插入/更新/删除，为什么还要在 .net 程序集中使用该程序集。
我在程序集 .Net 代码中看到的一些负面影响是，每次调用每个函数时，每个函数都会创建自己与 SQL Server 的连接，并且这些函数中使用的插入/更新/删除命令在 .Net 中是硬编码的代码。
我错过了什么吗？这种方法比使用存储过程更快吗？
【问题讨论】：
标签： .net sql-server assemblies
我不认为它比 SQL 更快，也不应该进行比较。因为托管存储过程不是 SQL 存储过程的替代品。只有当我们想要使用一些 .net api 时，才会使用托管代码，即 .Net dll 作为存储过程。我的意思是，如果我想在从/向数据库检索/插入图像时进行一些图像处理，这可以使用.Net，那么我将创建一个托管存储过程。
【讨论】：
你不会的。
TL；DR 版本：我不会将 CLR 用于简单的更新/插入/删除/选择操作。
有时人们只是喜欢使用新的闪亮的东西，因为它们是新的和闪亮的，或者因为他们有一些误解，认为它们在所有情况下都更好。
以MERGE 为例 - 人们喜欢这种不直观且难以学习的语法，因为它是新的，并且他们相信原子性和保护免受默认情况下不能保证的竞争条件（但他们假设已承诺） ，并且他们也忽略了有大量未解决的错误（请参阅this article）和several colleagues simply say not to use it at all。
对于 CLR，人们倾向于概括“哦，它是编译的，所以它必须比 T-SQL 快，后者是解释的”。 CLR 有一些非常好的用例，其中 比 T-SQL 更好（想想 RegEx，可能是最古老的用例，它没有原生 T-SQL 实现（背景 @987654323 @)，或者我的最爱之一，拆分字符串，如果你不能使用 TVP - 背景here，here 和 here)。不幸的是，CLR 的互操作开销使其成为简单数据检索和数据操作任务的糟糕选择。 This blog post 表明 FOR XML PATH 在一个特定用例中的性能优于 CLR。对于一般的数据操作和数据检索操作（通常称为 CRUD），它们不使用 T-SQL 中不直接提供的功能，或者不需要性能极差的大量字符串操作，我不会使用 CLR .即使在这些情况下，我也会使用 CLR 函数或过程来完成所需的繁重工作，但仍然使用 T-SQL 执行基本的 CRUD 操作。
其他一些可能对阅读有用的链接：
【讨论】：