方案： 实体1可以包含0个或更多实体2。
尝试做什么： 当实体1中的字段更新时，实体2中的字段将连续更新。
我在做什么：
通过update sql更新实体1中的字段，然后查询相关的实体2记录（使用SELECT ATTR FROM ENTITY2 WHERE ENTITY1.ID = ENTITY2.ENT1_ID），以便在对该记录进行更新之前获取ENTITY2 attr的旧值。 ENTITY2记录的更新类型（例如减去或添加）基于ENTITY1上的更新值。
替代方案： 使用触发器连续更新这些相关记录。
（我仍然计划研究实施触发器，但我不确定它是否值得。 对此有任何帮助吗？还是链接？）
使用触发器会更好吗？或者只是坚持我当前的解决方案（我认为由于sql执行的数量很慢，但更容易追踪）。
答案 0 :(得分：0)
有些人，例如Tom Kyte，他们认为触发器应该尽可能少地使用，如果有的话。 还有其他人，例如Toon Koppelaars认为应该使用它们，如果仔细考虑它们的话。
我是第二阵营并且相信可以使用触发器。但是，这种用法不应该是“自动”导致级联操作，例如您所建议的。相反，这些触发器可用于强制使用表约束子句的标准机制无法声明的完整性约束，即触发器本身不会从表中执行除SELECT之外的DML。 （注意：还有其他可以强制执行这些约束的机制，包括物化视图或引入其他列以及使用特定的索引策略）因此，我建议另一种方法。创建触发器 - 或使用这些替代机制 - 以确保不会提交破坏完整性约束的数据。然后使用PL / SQL创建API，这些API封装了确保完整性约束不被破坏所需的多表数据修正，并将它们用作更新路径。
通过这种方式可以确保数据库中不存在无效数据，而且实现此目的所需的实际DML不会在多个程序单元和触发器中隐藏在数据库中，而是在一个地方明确说明。 / p>
答案 1 :(得分：0)
可以过度使用触发器吗？当然。但这就是问题：任何都可能被滥用。我倾向于触发器，因为无法保证所有数据操作都将通过您的应用程序或任何单个通道。或者，如果可能，定义外键关系并让“级联更新”处理所有事情。我承认，很棘手，可能会有问题，但不要拒绝任何无法解决的问题。
话虽如此，我不知道是否需要为此目的触发。我不知道你为什么要将数据复制到另一个表中的字段。在不了解您的整体设计和您想要完成的任务的情况下，无法判断。但是考虑将数据保存在一个表中的一个字段中，然后使用视图将该字段公开为第二个“表”的一部分。更改它所在的数据，中提琴，它现在在任何地方都会被更改。
性能如何？是。但是将重复数据保存在不同的位置并使它们保持同步是一种数据完整性问题。只有你知道（或者能够找到）这种平衡倾向的方式。
哦，可以过度使用观点吗？当然。但是我总是提到这个问题;此外，在大多数数据库中，视图长期未被充分利用，过度使用将会有很长的路要走。