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

Question

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

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

我知道在 SQLCLR 中完成上述大部分(全部？)任务在技术上是可行的 - 我什至发现了许多文章解释如何从 SQLCLR 中使用 Web 服务，所以显然人们正在这样做。但我还在犹豫。 SQLCLR 曾经用于这种事情吗？如果不是，实际的缺点是什么？至于 SQLCLR 触发器相对于 Windows 服务的潜在好处，我只能看到一个:更少的数据库流量。我们预计最初​​的交易量非常小，因此 Windows 服务将产生一些“浪费”的流量。但该服务与数据库位于同一台机器上，因此它甚至不会影响网络，只会影响内部服务器资源。

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

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

Answer 1

在研究类似的流程时，我们考虑了一些事情。

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

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