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

Question

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

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

我知道在技术上可以做很多事情(所有？)在SQLCLR中的上述任务中--我甚至找到了许多文章，解释了如何在SQLCLR中使用web服务，所以显然人们正在这样做。但我仍在犹豫。SQLCLR有没有打算做这种事情？如果不是，有什么实际的缺点呢？至于SQLCLR触发器相对于windows服务的潜在好处，我只能看到一个:更少的db流量。我们预计最初的交易量会很小，所以windows服务会产生一些“浪费”的流量。但是服务和数据库在同一个盒子上，所以它甚至不影响网络，只影响内部服务器资源。

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

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

Answer 1

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

1. 当从属系统(邮件、ftp)不可用时会发生什么？
2. 故障恢复是如何工作的？
3. 如果我们处于故障状态，新记录会发生什么情况。即使我们知道系统已关闭，他们也会尝试执行post过程吗？
4. 支持生产系统的人员的技能集是什么？
5. 这个过程是如何在后处理系统消耗主系统资源的同时进行的？如何将它们分开?支持
6. 故障切换？

我们选择使用Windows服务，因为它为那些支持系统的人提供了最好的体验(他们会花更多的时间在服务器故障上，而不是堆栈溢出上)。因为它已经建立了停止和启动服务的方法，监控，集群支持，很容易将处理拆分到多台机器上，与事件日志记录集成等。

Answer 2

SQL CLR有一些设计目的-这不是其中之一，将这些东西放在插入触发器中真的会让婴儿耶稣哭。

一种可能的解决方案是使用查询通知来减轻服务和数据库之间的负载-另一种方法是允许通过UDP或类似的轻量级东西“pinged”服务-这意味着您不会在插入时导致大量事件发生(因此您不会锁定底层表过长的时间)。