SQL CLR 调用的替代方法是什么？答案

【问题标题】：what is the alternative of SQL CLR calls?SQL CLR 调用的替代方法是什么？
【发布时间】：2019-02-22 03:06:30
【问题描述】：

我将 SQL Server 2016 用于我的 .Net 应用程序[Framework 4.5]。我在 SQL 中使用 CLR 调用根据 CRUD 操作将一些数据传递给客户端/浏览器。

例如：SignalR 通知/调用、使用程序集的 Web 服务调用

我们是否有任何替代方法，即 SQL Server CLR 来进行直接 Web 服务调用。任何建议/帮助将不胜感激

【问题讨论】：

如果您可以解释您正在寻求/寻求避免的功能可能会有所帮助，以便您需要替代方案。 SQL CLR 有什么问题？
SQLCLR 从来都不是进行 Web 服务调用的选项。这就是 SSIS 等客户端应用程序和服务的工作
如果您想执行 CRUD，只需使用 ADO.NET。如果要编排 Web 服务，请构建编排 Web 服务。或者让服务相互交谈。如果您想让一个服务调用另一个服务，请相互添加一个服务引用。您必须解释您实际尝试做的事情。
OP 有一个 XY 问题.....
@MitchWheat 更像是“我继承了这个可怕的遗留应用程序，但不知道如何处理它”。为了首先找到修复程序，必须找到该遗留应用程序所做的事情。 SQLCLR 只是一个症状

标签： .net sql-server sql-server-2016 sqlclr

【解决方案1】：

如果您可以根据数据库中发生的事情进行调用，那么上面@lasse 建议让服务检索数据并进行必要的调用是个好主意。

除此之外，SQLCLR 可能是您最好的选择。我知道 SQL Server Service Broker 有外部调用的概念，但是几年前我研究了一下，性能并不存在。

第三种选择可能是使用 SQL Server 机器学习服务及其 Python 功能调用数据库并让您的调用在外部执行。但是，这需要 SQL 2017。在 2016 年，您可以使用 R，但我不知道 R 是否有能力做您想做的事情。

希望这会有所帮助！

尼尔斯

【讨论】：

没有 SQLCLR 从不用于 Web 服务调用。这是一个非常糟糕的想法，自 2005 年引入 SQLCLR 以来，一位作者和演讲者就警告过这一点。这是因为 SQLCLR 会延迟事务并消耗数据库用于缓冲的相同内存。 ML 服务也完全不合适。它是关于机器学习，而不是脚本。您不需要 ML 服务即可在外部服务器运行 Python 脚本
@PanagiotisKanavos - 由于EXTERNAL_ACCESS 明确授予出站呼叫的 DNS 和 Web 服务权限，我认为认为此类呼叫没有预料到是一种延伸。
@Damien_The_Unbeliever 自 2005 年起积极劝阻，原因我给出了。甚至在那时 Teched 演讲者也会谈论他们的“不，不要那样做！”经验。此外，仅在几年前，2005 年看起来不错的想法才被认为是一个相当糟糕的主意。有些东西是出于营销原因，而不是为了任何真正的技术利益。 2005 年在 WS-* 之前，当时人们认为 Web 服务是生命、宇宙和一切的答案。
@PanagiotisKanavos，很容易说“SQLCLR 从来都不是用于 Web 服务调用的。这是一个非常糟糕的想法”。我很想知道您将如何解决问题，如果您需要根据数据库中发生的事件对 Web 服务等进行一些调用，并且您无权访问导致这些事件发生的应用程序在数据库中。我还对您实施了多少 SQLCLR 解决方案以及它们做了什么感兴趣。
@PanagiotisKanavos 我和 Niels 一起讨论这个问题（这并不奇怪 ;-)。每当有人提及此主题时，您持续的反对充其量已过时。 2005 年任何人说什么都没关系。2012 年 re: 性能（改进的内存（包括 SQLCLR 操作的地方）和常量折叠 UDF；64 位也有很大的不同）做出了巨大的改进。而且，大多数人不（而且许多人仍然不）了解如何正确使用 SQLCLR / 最佳实践。说 SQLCLR“消耗内存并延迟事务”是不诚实的，因为所有操作都做这些事情。是的，（续）

【解决方案2】：

我们的一个客户有类似的基础架构，用于在 2 个不同的系统之间进行通信。

在表触发器中使用 SQLCLR 的第一种方法

表上的触发器调用 SQLCLR 过程，该过程发出 HTTP Web API 请求以发布数据。

发现问题：由于是完整的事务范围，前端触发的 CRUD 操作开始等待 SQLCLR 发布消息。

第二种方法是制作 SQLCLR 过程来实现异步 HTTP 请求

使用线程命名空间将 SQLCLR 过程作为异步方法。

发现问题：即使是这种方法也会导致问题，并且在端点不可用时会丢失消息。

使用 SQL SERVICE BROKER 作为 SQLCLR 的包装器的第三种方法

实施了 SQL 服务器代理来中断触发器和发布消息之间的事务。并从 SQL 服务代理目标激活存储过程发出 HTTP 请求。这解决了问题，因为它在添加到队列后会中断事务。

优势使用服务代理作为 SQLCLR 的包装器，您可以中断事务，消息存储在队列中并且永远不会丢失，我们也可以使用服务代理如果需要，可以在 2 个不同的 SQL 服务器实例之间进行通信。

【讨论】：