场景:实体1可以有0个或多个实体2。
尝试做什么:当实体1中的字段被更新时,实体2中的字段被连续更新。
我在做什么:通过Update sql更新Entity 1中的字段,然后查询相关Entity 2记录(使用SELECT ATTR FROM ENTITY2 WHERE ENTITY1.ID = ENTITY2.ENT1_ID
),以便在更新记录之前获得ENTITY2 attr的旧值。ENTITY2记录的更新类型(例如减法或加法)基于ENTITY1上的更新值。
替代方法:使用触发器连续更新这些相关记录。
(我仍然计划研究实现触发器,但我不确定是否值得这样做。能帮上忙吗?或者链接?)
使用触发器更好吗?或者只是坚持我当前的解决方案(我认为由于sql执行的数量,它相当慢,但更容易跟踪)。
发布于 2014-08-29 08:43:18
有些人,例如Tom Kyte,认为触发器应该尽可能少使用,如果有的话。还有其他人,比如Toon Koppelaars,认为如果仔细考虑它们的使用,就应该使用它们。
我属于第二阵营,我相信可以使用触发器。然而,这种使用不应该是“自动”的,因为你所建议的级联操作。相反,这些触发器可以用来强制完整性约束,这些约束不能使用表约束子句的标准机制来声明,即触发器本身除了SELECT from tables之外不做任何DML。(注意:还有其他机制可以强制执行这些约束,包括物化视图或引入额外的列和使用特定的索引策略),因此,我建议使用另一种替代方案。创建触发器-或使用这些替代机制-以确保不会提交违反完整性约束的数据。然后使用PL/SQL创建API,这些API封装确保不违反完整性约束所需的多表数据修改,并将其用作更新路径。
通过这种方式,您可以确保数据库中不存在无效数据,而且实现这一点所需的实际DML不会隐藏在多个程序单元和触发器中,而是在一个位置显式声明。
发布于 2014-08-30 22:06:56
汤姆·凯特很聪明。但从本质上讲,他仍然只是一名DBA。在考虑他关于表格设计的建议时,请始终牢记这一点。
触发器会被过度使用吗?当然了。但问题是:任何东西都可能被过度使用。我倾向于触发器,因为没有办法保证所有的数据操作都会通过你的应用程序或任何一个渠道。或者,如果可能的话,定义一个外键关系,让“级联更新”来处理所有事情。我承认这很棘手,可能会有问题,但不要马上拒绝任何解决方案。
话虽如此,我不知道是否需要一个用于此目的的触发器。我不知道您为什么要将数据复制到不同表中的字段。如果不知道您的总体设计和您试图实现的目标,就无法做出判断。但是可以考虑将数据保存在一个表的一个字段中,然后使用视图将该字段公开为另一个“表”的一部分。更改它所在的数据,viola,它现在无论出现在哪里都会被更改。
性能受到了影响?是。但是将重复数据保存在不同的位置并保持它们的同步是对数据完整性的打击。只有你知道(或有能力找出)这种平衡向哪个方向倾斜。
哦,视图会被过度使用吗?当然了。但总会有我提到的问题;此外,视图在大多数数据库中长期未得到充分利用,过度使用将是一条很长的路要走。
https://stackoverflow.com/questions/25553523
复制