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

Question

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

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

我知道在技术上可以在SQLCLR中做很多（全部？）上述任务 - 我甚至发现了一些文章，解释了如何从SQLCLR中使用Web服务，所以显然人们正在这样做。但我还是犹豫不决。 SQLCLR是否曾打算用于此类事情？如果没有，那么实际的缺点是什么呢？至于SQLCLR触发器对Windows服务的潜在好处，我只能看到一个：较少的数据库流量。我们预计最初​​的交易量非常小，因此Windows服务会产生一些“浪费”的流量。但是该服务与数据库位于同一个盒子上，因此它甚至不会影响网络，只影响内部服务器资源。

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

请分享您对这些不同方法的权衡的看法，或提出更好的选择。

Answer 1

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

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

我们选择使用Windows服务，因为它为那些支持系统的人提供了最佳体验（那些将花费更多时间在服务器故障而不是堆栈溢出的人）。因为它有一种既定的方法来停止和启动服务，监控，集群支持，易于分割处理到多台机器，与事件记录集成等。

Answer 2

SQL CLR有一些设计用于 - 而这不是其中之一，将这种东西放在INSERT触发器中真的会让小耶稣哭泣。

一个可能的解决方案是使用查询通知来减轻服务和数据库之间的负载 - 可以通过允许服务通过UDP“ping”或类似轻量级的东西来采取另一种途径 - 这意味着你不会在INSERTS上造成大量的事情（因此你没有锁定基础表超过一段时间）。