哪个更好？触发或选择 sql 然后更新记录？对于相关表多行更新答案

【问题标题】：Which is better? Trigger or Select sql then update records? for related tables multiple row updating哪个更好？触发或选择 sql 然后更新记录？对于相关表多行更新
【发布时间】：2014-10-22 14:16:15
【问题描述】：

场景：实体 1 可以有 0 个或多个实体 2。

尝试做什么：当实体 1 中的字段更新时，实体 2 中的字段会连续更新。

我在做什么：通过更新 sql 更新实体 1 中的字段，然后查询相关的实体 2 记录（使用SELECT ATTR FROM ENTITY2 WHERE ENTITY1.ID = ENTITY2.ENT1_ID）只是为了在更新该记录之前获取 ENTITY2 attr 的旧值。 ENTITY2 记录的更新类型（例如减去或添加）基于 ENTITY1 上的更新值。

替代方案：使用触发器连续更新这些相关记录。

（我仍然计划研究实现触发器，但我不确定是否值得。请问这有什么帮助吗？还是链接？）

使用触发器更好吗？或者只是坚持我目前的解决方案（由于 sql 执行的数量，我认为这很慢，但更容易追踪）。

【问题讨论】：

这取决于您的优先级，尽快更新 entity2 或 跟踪信息。如果要查找基于事件的事务，请选择触发器
我个人更喜欢在数据库中使用触发器进行操作。这样，我编写的任何未来代码，或者我必须做的任何手动更新，都会自动获得数据完整性。如果我在代码中执行此操作，我可能会在更新 entity1 时忘记更新 entity2，这样会不好。

标签： sql oracle plsql sql-update triggers

【解决方案1】：

有些人（例如 Tom Kyte）认为应该尽可能少地使用触发器（如果有的话）。还有其他人，例如Toon Koppelaars，认为应该使用他们，如果他们的使用经过仔细考虑的话。

我属于第二阵营，相信可以使用触发器。但是，这种用法不应该是“自动”引起您建议的级联动作。相反，这些触发器可用于强制执行无法使用表约束子句的标准机制声明的完整性约束，即触发器本身除了从表中选择之外不执行 DML。（注意：还有其他机制可以强制执行这些约束，包括物化视图或引入额外的列以及使用特定的索引策略）因此，我建议另一种选择。创建触发器 - 或使用这些替代机制 - 以确保不会提交违反完整性约束的数据。然后使用 PL/SQL 创建 API，以封装确保完整性约束不被破坏所需的多表数据修改，并将其用作您的更新路径。

通过这种方式，您可以确保数据库中不存在无效数据，而且实现这一点所需的实际 DML 不会隐藏在数据库中的多个程序单元和触发器中，而是在一个地方明确说明。

【讨论】：

【解决方案2】：

汤姆·凯特非常出色。但从本质上讲，他仍然只是一名 DBA。在考虑他对餐桌设计的建议时，请始终牢记这一点。

可以过度使用触发器吗？当然。但问题是：任何东西都可能被过度使用。我倾向于触发器，因为无法保证所有数据操作都将通过您的应用程序或任何单个渠道。或者，如果可能的话，定义一个外键关系，让“级联更新”处理一切。我承认这很棘手，而且可能会有问题，但不要立即拒绝任何解决方案。

话虽如此，我不知道是否需要为此目的的触发器。我不知道您为什么要将数据复制到不同表中的字段。如果不了解您的整体设计以及您要完成的工作，就无法判断。但是考虑将数据保存在一个表的一个字段中，然后使用视图将该字段公开为第二个“表”的一部分。更改它所在的数据，viola，现在无论它出现在哪里都会更改。

性能受到影响？是的。但是，将重复数据保存在不同的地方并保持同步会影响数据完整性。只有您知道（或有能力找出）这种平衡的倾斜方向。

哦，视图可以被过度使用吗？当然。但总有我提到的问题。此外，在大多数数据库中，视图长期未充分使用，以至于距离过度使用还有很长的路要走。

【讨论】：