5

我阅读了一篇关于在 sqlserver 中使用 CLR 集成的文章，并且想知道可能存在哪些潜在问题（如果有的话）。我的想法是使用它来验证遗留数据库中潜在的不良数据。一个例子是电话号码列中的人名。

编辑：我不认为有任何问题，但这不是我看到很多讨论的问题，并且想确保我不会打开以后会导致问题的罐头蠕虫。我问的原因是我的 DBA 在我问这个问题时看着我，就像我疯了一样。

4

4 回答 4

6

SQL Server 中的 CLR 集成本身并不不稳定。作为证据，我将向您指出一个事实，即在 SQL Server 2008 中，一堆系统数据类型被实现为 CLR 数据类型，例如新的地理和几何类型。因此，CLR 被认为足够安全，可以让新的核心功能基于它。

话虽这么说，CLR 为 SQL 编程带来了一个全新的武器库，让你自食其果。您可以启动线程、阻止 IPC 通信（事件、互斥体、信号量）、外部连接并等待 I/O、在内存中读/写、调用各种 Win32 APIS，并且通常会鲁莽行事并造成严重破坏。旧的 T-SQL 编程需要更强大的黑客才能来实现相同的目标。

您是否正在考虑实现一种新的数据类型，该数据类型公开了良好的、受约束的行为，例如字段的正则表达式验证？前进。您是否正在考虑从 SQL 托管的 CLR 内部发出 Web 服务请求？你有它的到来，你将应得的一切！

经验法则是，如果您的程序集将在没有值得信赖的要求（没有 EXTERNAL_ACCESS，没有 UNSAFE）的情况下加载和验证，那么您应该没问题。当然，您仍然可以在 SAFE 程序集中编写 while(1) {;} 循环，但是 T-SQL 存储过程也可以...

于 2009-07-09T18:40:21.227 回答
2

我看到的主要内容：

  • 非数据库的东西，例如执行注册表写入、停止/启动服务等的不安全权限
  • 避免编写 SQL
  • 更难调整、跟踪和调整

有一个关于 MS 试图将“日期”和“时间”实现为 SQL Server 2005 的 CLR 数据类型但失败的故事......（Itzak Ben-Gan 在 2004 年的一次研讨会上）

于 2009-07-09T17:44:40.603 回答
2

一个问题是如何将 CLR（生产）组件安装到服务器上。例如，我们公司有一些客户不让我们访问他们的 SQL 服务器，而是通过 SSMS 进行远程连接。因此，没有可以部署您的组件 dll 的本地路径。解决方案是将二进制文件作为二进制 blob 或 0x -hex 字符串上传到临时表。

那么当你更新一个函数/存储过程时会发生什么？您无法更新依赖于另一个程序集的某些程序集（我不记得它是否仅在函数签名更改时..）。我认为在上传任何程序集的新版本之前，我们总是会删除所有 sp/func/assys。

构建/参考系统集成是愚蠢的。添加对 sqlclr 的引用时，必须将该 dll 部署到 SQLS。VS 会将该 dll 从 SQLS 复制到该项目的“obj/sqlclr”目录，然后从那里使用它。然后，当您使用 TFS 构建系统构建该项目时，您必须拥有该 dll 以使构建成功。（有涉及共享 SQLS 服务器的解决方法，但是..）。

当 SQLS 部署了生产 dll 时，VS 将无法部署新的 dll。解决方案是删除生产 dll。

让调试器与 SQLCLR 一起工作是个婊子。我们经常因为在“sqladmin”（或类似的）组中没有我们的域用户名（DOMAIN\username）而被绊倒。VS/SQLS 几乎没有什么建议可以告诉您什么是错误的，以及为什么它无法达到断点。

然后，即使在编写 C# 时，最终也会用硬编码字符串编写 SQL。我不知道是否存在一些帮助来避免这种废话，sqlclr 没有 nhibernate/sqlalchemy。这主要是在需要处理许多行/等的 SP 中。功能受此影响较小。

这也意味着如果您在 BL 层中使用 nhibernate 或类似的东西，您可能无法在 sqlclr 层中重用它，并且您将复制类。从 SqlReader 实例化对象在 2009 年非常非常非常令人讨厌。MS 的想法超出了我的想象，令人难以置信的废话。

总而言之，我认为 SQLCLR 比 T-SQL 好得多，但在某些情况下最终只是编写一个 T-SQL SP，因为它不那么麻烦。

于 2009-07-09T19:08:24.070 回答
1

我遇到的一个问题是上下文连接的行为方式不合理（如 SO 上的链接问题所示）

尽管如此，我认为CLR很棒。

于 2009-07-09T17:22:05.003 回答