触发器和 PHP 代码哪个更有效？

Question

我的要求是在患者出院后将患者的 EMR 数据移动到一组历史记录表中。我建议在放置放电标志的桌子上使用一个后触发器，检查标志上的新\旧值，以确保我只在标志最初设置为放电时才采取行动。编写 PHP 端的高级应用程序开发人员表示，在 PHP 中执行此操作至少比触发器快 4 倍。对我来说这没有任何意义，但我的背景是 SQL Server，而不是 MySQL，所以我正在向社区寻求帮助。

附加信息：即使在患者出院后，也大量使用装有出院标志的桌子。当前有 7 个窄表（总共约 70 列）可以通过触发器插入数据。

Answer 1

我想知道“至少快 4 倍”从何而来？有太多的变量在起作用，甚至无法得出这样的数字，无论如何，性能差异（无论多么微小）都应该是相反的。

表上触发器的存在确实会带来性能损失，但如果您的触发器是智能编写的，则应使用“可忽略”一词。一个行为良好的触发器只做它需要做的事情，然后让步，在测试多个条件的触发器的情况下，测试是嵌套的，以便为每次运行尽可能少地进行逻辑比较扳机。

一些开发人员似乎抵制触发器的原则是“黑魔法”” -- “哎，数据库里有些东西变了，应用程序没变。这很糟糕。”诚然，触发器的存在是开发人员和 DBA 等在进行故障排除时必须牢记的事情，如果它们在您的环境中不常见，则尤其如此。如果触发器修改的表之一的结构是更改——比如说，一个重命名的列——然后对放电标志的更新突然开始抛出关于更新查询中甚至没有引用的列的错误，某人没有“可能涉及触发器”的可能性至少在他们的脑海里，他们可能完全糊涂了。我也曾站在那一边，我是最初写的人——然后忘记了——有问题的触发器。那个'

我想说的是，您提出的问题既是原则问题又是性能问题：正如这个问题的一个答案所指出的那样，数据库应该负责管理数据库......而不是应用程序。应用程序不应该负责参照完整性，那么为什么它应该负责操作——就像这个，据我所知——应该是原子的？

如果根据定义，当放电标志被设置时，EMR数据应该在历史表中，那么我原则上认为标志的设置应该是将数据放在那里的原因。这需要触发器...或调用存储过程，该过程既设置放电标志，又在返回之前迁移记录。

我想象无论你最终如何迁移记录，执行迁移的实际查询都是一样的......所以实际上很难想象性能差异是巨大的，因为执行时间移动记录的查询不会有所不同，无论查询是从触发器运行，从存储过程运行，还是与应用程序分开运行......所以，几乎可笑的是，我期望的最重要的因素find 可能很小：运行 PHP 的系统和运行 MySQL 的系统之间的往返时间乘以需要运行的单独查询的数量，这可能是触发器（或存储过程）速度的决定因素) 的实现将是......并且在具有亚毫秒 RTT 的 LAN 上......并不多。