我应该使用数据库触发器来解决以下问题吗？

Question

我接到了以下任务：

外部源将以随机间隔将名称，日期时间和值写入数据库表（表A）。我需要将此数据复制到另一个表（表B）并删除表A中的行。如果查找表中不存在该名称，则该行需要保留在表A中，直到它执行，然后复制到表中乙

上述情况听起来像数据库触发器可以有效使用的情况，还是更好地创建一个外部应用程序（可能是Windows服务），每5分钟检查一次数据库并执行必要的更新？

更新

这不一定是即时的，因此如果我使用Windows服务或任务调度程序，它可能会以5分钟的间隔设置。如果使用触发器几乎是即时的，只是使用触发器的好处，而不是决定因素。

我主要担心的是这是使用触发器的正确​​方法吗？应该使用触发器来复制数据还是这种不好的做法？使用触发器也可能有问题，例如，如果复制失败，它是否可以锁定表，从而阻止后续行被复制？如果一个副本花费的时间太长，它是否会处理在总线上插入的行？如果我不使用触发器，那么有一个更好的解决方案，例如使用Windows日程安排的Windows服务或控制台应用程序？

由于

Answer 1

您可以使用SQL Job执行此操作。写入存储过程以复制数据并放入计划作业。这项工作将在每5分钟后运行一次。

step_by_step_guide_to_add_a_sql_job_in_sql_server_2005

sql_server_agent_jobs

Answer 2

这听起来像一个非常简单的操作。如果是，并且从表A中删除行并将其插入表B并不需要花费太多时间，我会去寻找触发器。这样做的好处是数据始终是最新的，而不是定期同步。

我假设你无法控制数据的插入方式，或者我建议让外部源通过存储过程写入数据库。这也可以提高安全性。

Answer 3

如果这是同类中唯一的任务，并且您不希望有更多任务，那么触发就足够了。这听起来像一个简单的数据操作。最好把代码放在一些存储过程中。服务将是一种过度杀伤。

这些任务的问题在于它们往往会增长。我已经看到简单的数据操作逻辑，以成长为巨大的业务逻辑动物，吞噬程序员的理智。因此，如果你从一个无辜的触发器/存储过程开始，只是感觉到有更多的可能性，然后运行并从中提供服务！

Answer 4

编写一个简单的触发器，并在事务中执行检查和所需的更新。

Answer 5

触发器是解决方案。它也恰好是交易的一部分。所以，整件事发生或失败。

Answer 6

只要逻辑很简单，我就说继续使用触发器。当触发器实现复杂的逻辑时，问题就开始出现，但如果它只是“验证查询表中是否存在数据，是否将数据从A复制到B并从A中删除”。

您还可以考虑查找表上的第二个触发器，以便在将新名称添加到查找表时，可以执行将行从需要新名称的行移动到表B等所需的任何处理。 / p>

分享并享受。

Answer 7

触发器引诱你作为一个简单的修复，但不久之后，你花费更多时间调试触发器而不是读取StackOverflow。触发器是邪恶的。远离他们。

Answer 8

我同意穆罕默德的观点。这应该使用数据库作业完成。

在这种情况下使用触发器似乎与我相反。您正在使用触发器来修改您在表A中插入的数据，但是（可能）在表B中执行某些操作并阻止该行插入表A中。

此外，如果您在表A中插入了一行不存在该行的情况，则该行将保留在表A中。这意味着您的触发器必须是表级别，而不是行级别。

触发器的主要用例是修改插入数据，添加修改日期等信息。

您应该编写存储过程并每五分钟运行一次。这更简单，当逻辑变化更容易理解时。