Sql 基于计时器的事件触发器

我目前正在从事一个有特定要求的项目。以下是这些项目的简要概述：

• 从外部Web服务检索数据
• 数据存储在SQL 2005中
• 数据通过web GUI进行操作
• 与web服务通信的windows服务与我们的内部web UI没有耦合，除非通过数据库
• 与web服务的通信既需要基于时间，也需要通过web UI上的用户干预触发

web服务通信触发的当前（预生产）模型是通过存储手动干预生成的触发请求的数据库表实现的。我真的不希望有多个触发器机制，但希望能够根据调用时间使用触发器填充数据库表。在我看来，有两种方法可以做到这一点

1） 调整触发器表以存储两个额外参数。一个是“这是基于时间的还是手动添加的？”和一个可空字段，用于存储计时详细信息（具体格式待定）。如果是手动创建的触发器，则在触发触发器时将其标记为已处理，但如果是定时触发器，则不标记为已处理。
或
2） 创建第二个windows服务，以定时间隔动态创建触发器

第二个选项对我来说似乎是一个骗局，但选项1的管理很容易变成编程噩梦（您如何知道表的最后一次轮询是否返回了需要触发的事件，以及如何在下次轮询时阻止它重新触发）

---

如果有人能抽出几分钟来帮我决定走哪条路线（这两条路线中的一条，或者可能是第三条，未列出的路线），我将不胜感激。

我的看法是这样的

您有一个Windows服务，它扮演着调度程序的角色，其中有一些类只需调用Web服务并将数据放入数据库中

因此，您也可以直接从WebUI使用这些类，并基于WebUI触发器导入数据

我不喜欢将用户生成的操作存储为数据库中的标志（触发器），在数据库中，某些服务将轮询它（以不受用户控制的间隔）以执行该操作

您甚至可以将整个代码转换为exe，然后使用Windows调度程序进行调度。并在用户从Web UI触发操作时调用相同的exe。

@Vaibhav

不幸的是，解决方案的物理架构不允许组件之间进行任何直接通信，除了Web UI到数据库和数据库到服务（然后可以调用Web服务）之外。然而，我同意重复使用通信类将是这里的理想——我只是不能在我们的业务范围内这样做*

---

*技术上“更好”的解决方案不总是受到外部因素的阻碍吗？

为什么不使用SQL作业而不是Windows服务？您可以将所有db“触发器”代码封装在存储过程中。然后，您的UI和SQL作业可以调用相同的存储过程，并以相同的方式创建触发器，无论是手动创建还是按时间间隔创建