我应该为以下问题使用数据库触发器吗?

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

step_by_step_guide_to_add_a_sql_job_in_sql_server_2005

sql_server_agent_jobs

这听起来像是一个非常简单的操作。如果是这样,并且从表A中删除行并将其插入表B并不需要太多时间,那么我将使用触发器。这样做的好处是数据总是最新的,而不是定期同步。

我假设您无法控制如何插入数据,或者建议让外部源代码通过存储过程写入数据库。这也可以提高安全性。

如果这是这类任务中唯一的一项,而你并不期待更多的任务到来,那么一个触发器就足够了。听起来像是一个简单的数据操作。最好把代码放在一些存储过程中。一次服务就太过分了。

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

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

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

触发器作为一个简单的修复程序吸引您,但不久之后,调试触发器的时间比读取StackOverflow的时间要多。触发器是邪恶的。离他们远点。

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

在这种情况下使用触发器对我来说似乎是违反直觉的。您使用的触发器不是修改要插入到表a中的数据,而是(可能)在表B中执行某些操作,并阻止该行插入到表a中。

另外,如果在表a中插入了一行,而该行的键不存在,那么该行将留在表a中。这意味着您的触发器必须是表级别的,而不是行级别的。

触发器的主要用例是在插入时修改数据,添加诸如修改日期之类的信息。

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