sql - 基于定时器的事件触发器

Question

我目前正在从事一个具有特定要求的项目。简要概述如下：

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

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

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

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

score 3 · Accepted Answer

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

score 0 · Accepted Answer

我的看法是这样的。

您有一个 Windows 服务，它扮演调度程序的角色，其中有一些类可以简单地调用 Web 服务并将数据放入数据库中。

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

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

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

score 0 · Accepted Answer

@Vaibhav

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

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

3 回答 3