SQLServer CLR 与 T-SQL 相比有哪些优势?使用 .NET 语法是否比 T-SQL 更容易?我看到您可以定义用户类型,但我不太清楚为什么这样做更好。例如,您可以定义一个电子邮件类型,它会有一个前缀属性和一个域属性。然后,您可以搜索域或前缀或两者。但是,我看不出这与添加几列有什么不同,一列称为前缀,一列称为域并单独搜索它们。也许有人有现实世界的理由为什么这更好。
4 回答
我将举一个很好的例子:CLR 有一个内置的 RegEx 对象,这在 SQL Server 中是非常缺乏的。现在编写函数来执行基于正则表达式的验证约束/修复是微不足道的。
不同的目的。CLR 存储过程对于编写高度过程化的代码或使用 T-SQL 无法访问的系统设施会带来好处的事情很有用。尽管没有内在的理由不能针对它编写应用程序存储过程,但通常您不会将 CLR 存储过程视为一种仅用于编写应用存储过程的不同语言。通常,CLR sproc 的大多数用途将用于系统目的而不是应用程序组件,尽管这绝不是硬性规定。
CLR 集成层确实提供了一些 T-SQL 存储过程无法直接使用的功能,例如自定义聚合函数。它还提供对 .Net 库的访问,这对于访问 T-SQL 不支持的功能可能很有用。
T-SQL 做传统数据库的东西,并与查询优化器集成,因此它仍然最适合面向集合的数据库代码。有用于 CLR 存储过程的 API 挂钩向查询优化器提供信息,但这增加了一些复杂性。
还可以使用 CLR 集成来定义 T-SQL 代码可访问的函数。在某些情况下,这些函数比 T-SQL 函数更快且内存效率更高。Wrox 关于 CLR 集成的新闻书籍对此进行了深入讨论。
例如,您还可以从 SQLCLR 方法调用外部 Web 服务 - 在 T-SQL 中并不完全可能 :-)
马克
SQL Server 中的 SQLCLR / CLR 集成只是帮助解决某些(不是全部)问题的另一种工具。有些事情它比纯 T-SQL 做得更好,有些事情只能通过 SQLCLR 完成。我为 SQL Server Central 写了一篇文章,Stairway to SQLCLR Level 1:什么是 SQLCLR?(需要免费注册才能阅读那里的文章),这解决了这个问题。基础知识是(有关详细信息,请参阅链接的文章):
- 流表值函数 (sTVF)
- 动态 SQL(在函数内)
- 更好地访问外部资源/替换 xp_cmdshell
- 传入数据更容易
- 取回结果集的多列更容易
- 没有外部依赖(例如 7zip.exe)
- 通过模拟提高安全性
- 多线程能力
- 错误处理(函数内)
- 自定义聚合
- 自定义类型
- 修改状态(在函数内且不带
OPENQUERY
/OPENROWSET
) - 执行存储过程(只读;在函数内且不带
OPENQUERY
/OPENROWSET
) - 性能(注意:这并不是在所有情况下都有意义,但在某些情况下肯定取决于操作的类型和复杂性)
- 可以捕获输出(即发送到 SSMS 中的“消息”选项卡的内容)(例如,
PRINT
严重性= 0 到 10)——我忘了在文章中提到这一点 ;-)。RAISERROR
要考虑的另一件事是,有时能够在应用程序和数据库之间共享代码是有益的,这样数据库就可以深入了解某些业务逻辑,而无需构建自定义的、仅限内部的屏幕来访问该应用程序代码。例如,我曾在一个系统上工作,该系统从客户那里导入数据文件,并使用大多数字段的自定义哈希并将该值保存到数据库中的行中。这允许在再次导入数据时轻松跳过行,因为应用程序将从输入文件中散列值并与存储在行中的散列值进行比较。如果它们相同,那么我们立即知道所有字段都没有改变,所以我们进入下一行,这是一个简单的 INT 比较。但是用于进行哈希的算法仅在应用程序代码中,因此无论是用于调试客户案例还是通过标记至少有一个字段发生更改的行(来自我们的应用程序的更改)来寻找将某些处理卸载到后端服务的方法与在较新的导入文件中查找更改相反),我无能为力。这将是一个在数据库中拥有相当简单的业务逻辑的绝佳机会,即使不是用于正常处理;在数据库中拥有相当于编码值而无法理解其含义的内容使得解决问题变得非常困难。这将是一个在数据库中拥有相当简单的业务逻辑的绝佳机会,即使不是用于正常处理;在数据库中拥有相当于编码值而无法理解其含义的内容使得解决问题变得非常困难。这将是一个在数据库中拥有相当简单的业务逻辑的绝佳机会,即使不是用于正常处理;在数据库中拥有相当于编码值而无法理解其含义的内容使得解决问题变得非常困难。
如果有兴趣在不编写任何代码的情况下查看其中的一些功能,SQL#的免费版本(我是它的作者)有 RegEx 函数、自定义聚合 (UDA)、自定义类型 (UDT) 等。