代码之家  ›  专栏  ›  技术社区  ›  annakata

Postgres:缩小触发范围

  •  1
  • annakata  · 技术社区  · 15 年前

    (8.3)

    我在用数据库表 X 100多个栏宽(很遗憾我无法更改),其中许多栏通过正常的业务流程经常更新。

    我有更新表格的要求 Y 基于特定列的更新 在里面 X 通过异常业务流程更新。但是,由于 X 只需应用一个检查 X.FO 决定是否更新 Y 被认为是不可接受的。

    Y 也不是这条线的尽头,有几条深深的祖先链,所有这些都需要向上冒泡到根部。

    我能想到的唯一解决办法是:

    • 打破 X 到多个表中(不允许)
    • 明确更新 Y (和) Z 以及其他)作为更新业务逻辑的一部分 X 但是,这将有一个很大的足迹,并为一些人留下了很大的空间,当他们必须在另一个过程中实现这一点时,可能会出错或丢失它。这显然不是很好的设计(我是 尝试 逐步修复)。

    有人知道如何按列或任何其他替代方法限制触发器执行吗?触发视图?其他巫毒?

    3 回复  |  直到 15 年前
        1
  •  2
  •   Magnus Hagander    15 年前

    您可能可以使用规则来做一些事情,但前面已经说过,触发器应该“足够好”。但是,如果您试图解决管理问题而不是技术问题,那么规则可能会帮助您。在执行期间,他们会提前申请。小心一些陷阱,它们通常有序列等等。

        2
  •  2
  •   Milen A. Radev    15 年前

    很遗憾,直到9.0版发布( which includes both column triggers and a WHEN clause for triggers )你必须求助于第二个解决方案。

        3
  •  0
  •   Community CDub    8 年前

    为什么标准触发器是不可接受的?运行一个函数,首先检查 NEW.column_name=OLD.column_name 如果相同的话,只需返回就可以了。你可以在一秒钟内发射数十万颗。您的系统可能无法每秒处理超过数百个事务-比这少3个数量级。

    有条件后,9.0中的延迟触发器将更快,但仅比普通触发器快2倍。见 a relevant post 在里面 Depesz 的博客。你可以在 Postgres 9 development version .