触发器与网络性能

Question

数据库触发器上有许多问题和响应，但是我没有发现任何与网络性能有关的问题，特别是触发器的好处(或其他方面)。

我有个案子：

表A有数据很重的行(1-2 KB的JSON数据)。当其中一个字段(状态)被更新时，整个记录必须移动到另一个表(归档)，并从表A中删除。一次可以更新多个行。

在不涉及归档表设计的优点的情况下，我已经在一个触发器(表A的“更新后”、复制记录和删除)中实现了这一点--我的逻辑是，不需要将数据发送到应用程序(它是一个应用程序，云上有dB )并再次返回。

我相信这将改善终端用户体验，减少网络流量，降低不良网络的风险问题。

触发器是否仍然是“避免--这些都是坏的”？

Answer 1

触发器的问题是，它们经常被滥用，即使被用于一个好的目的，也常常被错误地写入。

触发器的主要合法用途是增强数据的基本完整性，但不能用标准SQL约束来表示。我说的是根本的约束，即使是暂时的，也不可能被违反，比如日志条目必须始终保持零的平衡。

另一个合理的实际用途是作为一个旧的应用程序的截取点，该应用程序的工作不再能够安全和正确地改变。就像临终病人的类阿片一样，这些触发物会加速死亡，但可能是为了缓解剩余的时间。

Bolt-on审计/历史表是一种简单而常见的模式，可以说是触发器的更合理的使用。对变更进行审计并不总是一个“基本”约束，但它通常是相当高的。

唯一要记住的是，开发人员和管理员通常没有意识到触发器的存在。

如果触发器不是基本的--如果它们只涵盖通常的操作，但在高层干预或批量更新的情况下可能被忽略--那么开发人员和管理员将不会意识到他们的存在，直到他们的无知已经造成损害或功能障碍。

我见过即使是(完全不合适)触发器的创建者也会以这种方式陷入他们自己的网络。

如果触发器只覆盖某些表，或者触发器的功能(全部视为一个整体)是任意的、变化的或复杂的，那么无知就很可能占据主导地位。

无论何时触发器不应100%触发，或者如果它们只执行最简单和最可预测的工作，则应该优先使用存储过程而不是触发器，并且前端应用程序应该重新工作以使用这些存储过程。

Answer 2

就网络性能而言，使用触发器将数据从一个表移动到另一个表，然后从原始表中删除数据，可能会在短期内减少网络通信量，因为数据是在数据库内部传输和删除的，而不是通过网络发送到应用程序，然后返回到数据库。然而，必须考虑以这种方式使用触发器的长期影响。

例如，如果触发器运行在具有大量更新的大型表上，则在数据库试图跟上更新并为每个更新运行触发器时，它可能会给数据库带来性能问题。这可能导致查询性能下降，并导致数据库崩溃或失去响应。在这种情况下，当用户试图访问数据库时，触发器可能会增加网络流量，但由于数据库正忙于运行触发器，因此无法访问数据库。

总之，在决定是否在数据库中使用触发器之前，最好仔细考虑使用触发器的潜在缺点，并将其与好处进行权衡。在某些情况下，触发器可能是有用的工具，但应该谨慎使用。

Answer 3

实际上，触发器的好处是在db服务器上进行处理:避免了对客户端的不必要的事务处理，避免了命令返回的额外解析和执行开销，更不用说事务性性能(减少锁定时间等)。

缺点是，在一个面向数据的体系结构中，您经常被锁定在私有触发器定义中，并且更有问题，在处理过程的一部分中，封装/响应性丢失是在客户端上完成的，有些是由服务器接管的，在维护周期中，谁在做什么就变得不清楚了。实体的所有权在db和单个应用程序之间被稀释。

另一种办法是让服务控制实体。然后将触发器活动移动到相应的服务中。由于该服务通常是在同一个数据中心中操作的，具有较高的(内部)带宽，因此用户几乎不会注意到不使用触发器的网络影响。对于非常大的卷，您必须决定是在触发器的帮助下优化服务，还是扩展分区、分发数据库(这不是服务方法的问题，但可能很难通过假设所有数据都是db服务器本地的触发器来实现)。