在Sqlserver中CLR集成可能存在哪些问题

Question

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

编辑： 我认为没有任何问题，但这并不是我看到很多讨论的事情，并且想要确保我没有打开一个可以在以后引起问题的蠕虫。 我问的原因是我的DBA看着我，就像我在询问它时一样疯狂。

Answer 1

SQL Server本身的CLR集成并不稳定。作为证据，我将向您指出，在SQL Server 2008中，一堆系统数据类型被实现为CLR数据类型，如新的geography and geometry类型。因此，CLR被认为足够安全，允许新的核心功能基于它。

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

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

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

Answer 2

我看到的主要内容：

• 非数据库内容，例如UNSAFE进行注册表写入，停止/启动服务等权利
• 避免编写SQL
• 更难调整，追踪和调整

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

Answer 3

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

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

构建/参考系统集成是愚蠢的。添加对sqlclr的引用时，必须将该dll部署到SQLS。 VS会将该SQL从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层中重用它，你将复制类。在2009年，从SqlReader实例化对象是非常非常非常糟糕的。在MS的想法是超出我的，令人难以置信的废话。

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

Answer 4

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

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