SQLCLR 触发器与 Windows 服务。什么时候适合使用 SQLCLR？

Question

我们有一个带有 SQL Server 2005 后端的 .NET 电子商务应用程序。新订单需要一定的“后处理”。这些任务包括发送电子邮件、创建文件、将文件上传到 FTP 服务器以及对 WCF 数据服务执行 CRUD 操作。执行所有这些任务的代码已经作为几个 .NET 类库存在。

我的团队正在争论的是将这段代码放在哪里。我编写了一个简单的 Windows 服务，它定期轮询数据库，并在检测到数据库中的新事务（基于标志）时，它会执行必要的操作并记录任何错误。已提出的替代方案是将触发处理的 SQLCLR INSERT 触发器。

我知道在 SQLCLR 中完成上述大部分任务（全部？）在技术上是可行的——我什至发现了许多文章解释了如何从 SQLCLR 中使用 Web 服务，显然人们正在这样做。但我仍然犹豫不决。 SQLCLR 曾经打算用于这种事情吗？如果没有，实际的缺点是什么？至于 SQLCLR 触发器相对于 Windows 服务的潜在好处，我只能看到一个：更少的数据库流量。我们预计最初​​的交易量很轻，因此 windows 服务会产生一些“浪费”的流量。但是服务和数据库在同一个盒子里，所以它甚至不影响网络，只影响内部服务器资源。

最后，第三种可能性是使用 SQLCLR 触发器在文件系统上保存一个简单的令牌，并使用 Windows 服务中的 FileSystemWatcher（而不是 Timer）来根据需要执行任务。

请分享您对这些不同方法的权衡取舍的想法，或提出更好的替代方案。

Answer 1

在查看类似流程时，我们考虑了一些事情。

1. 当依赖系统（邮件、ftp）不可用时会发生什么？
2. 如何恢复故障？
3. 如果我们处于失败状态，新记录会发生什么情况。即使我们知道系统已关闭，他们是否也会尝试进行后期处理？
4. 支持生产系统的人员具备哪些技能？
5. 如何监控此过程？
6. 后处理系统是否在处理时消耗主系统的资源？您将如何将它们分开？
7. 是否支持故障转移？

我们选择使用 Windows 服务是因为它为那些支持系统的人（那些愿意花更多时间在 serverfault 而不是 stackoverflow 上的人）提供了最佳体验。由于它有一个既定的方法来停止和启动服务、监控、集群支持、易于将处理拆分到多台机器、与事件日志集成等。

Answer 2

SQL CLR 是为某些事情而设计的——这不是其中之一，将这类东西放在 INSERT 触发器中真的会让婴儿耶稣哭泣。

一个潜在的解决方案是使用查询通知来减轻服务和数据库之间的负载 - 可以通过允许通过 UDP 或类似的轻量级“ping”服务来采取另一条路线 - 这意味着您不会在 INSERTS 上导致大量发生（因此您不会长时间锁定基础表）。