Web 上有一些教程描述了使用 SQL Server 2005 的 CLR 集成来使用 Web 服务。大多数情况下，这个过程似乎相当复杂。我遇到了几个问题，包括需要更改数据库的信任级别，以及使用 sgen 工具创建静态 XmlSerializer 程序集；而且我还没有让它正常工作......（我确定我只需要投入更多的时间和精力）
采用这种类型的架构时，安全性、性能和维护方面的影响是什么？这可能是一个相当频繁使用的过程，并且易于维护是相对重要的。
我可以自由选择是将它作为 UDF 集成到 SQL Server 中，还是让它成为控制台/Web 应用程序的独立 .NET 库。SQL CLR 与外部程序集的集成值得麻烦吗？
The short answer is, no, SQL CLR Integration is probably not worth the trouble.
The longer answer has several points, beginning with programming CLR in the database. It's a fine tool, when used correctly, but it does increase memory consumption and can lead to performance issues if not done correctly. I use it in my database for very specialized functionality, such as adding RegEx ability, but it's used sparingly, with well-tested code to prevent as many issues as possible from cropping up.
A second is, as you pointed out, you've got to modify security, opening up potential risks.
Use a stand alone application to load the data into your server. You'll have more control, less risk and a much easier time of it.
我想你已经回答了你自己的问题，我个人发现任何调用 WebService 的东西都比 likley 更适合存在于 SQL Server 之外。复杂性、提高的信任级别，以及正如您提到的整个复杂过程，使得解决方案难以记录和维护。
我一直在做 clr 程序，它在 Exchange 和 AD 上调用 web 服务，我同意上面的帖子。它可以工作，但是我们很快就遇到了内存不足的问题，因为在 sql server 中的 CLR 中处理内存的特殊方式。正如您可以想象的那样，小型查询的性能还可以，但根本无法扩展。
通常，您的数据库性能决定了您的应用程序的性能，如果您无法完全控制自己在做什么，我认为将此类逻辑放入数据库中是不可以的。
使用 CLR 进行不依赖于外部资源的简单文本操作和其他计算。