©
Dokumen ini menggunakan Manual laman web PHP Cina Lepaskan
许多用触发器可以干的事情同样也可以用PostgreSQL规则系统来完成。 目前不能用规则来实现的东西之一是某些约束，特别是外键。 可能在某字段的值没有在另一个表里出现的情况下用一条有条件的规则把查询重写为NOTHING。 不过这样做数据就会被不声不响的仍掉，因而这也不是一个好主意。 如果需要检查有效的值，而且如果是无效值出现时要生成一个错误信息，这种情况下要用触发器来做。
另一方面，因为在视图关系里没有可供扫描的真实数据，因而触发器将永远不被调用。 然而在 INSERT、UPDATE 或 DELETE 时可以创建试图。
对于两者都可用的情况，哪个更好取决于对数据库的使用。 触发器为任何涉及到的行执行一次。规则修改查询树或生成额外的查询。 所以如果在一个语句中涉及到多行， 一个生成额外查询的规则通常可能会比一个对每一行都分别执行一次(因此要执行很多次)的触发器快一些。 不过，触发器的方法从概念上要远比规则的方法简单，并且很容易让新手可以做正确事情。
下面展示一个在同一个情况下选择规则与触发器的对比例子。例如这里有两个表：
CREATE TABLE computer (
hostname text, -- indexed
manufacturer text -- indexed
);
CREATE TABLE software (
software text, -- indexed
hostname text -- indexed
);
两个表都有好几千行，并且hostname上的索引是唯一的。 规则/触发器应该实现这样一个约束，这个约束从software表中删除引用已删除计算机的行。 触发器可以用下面这条命令：
DELETE FROM software WHERE hostname = $1;
因为触发器是为从computer, 里面删除的每一个独立的行调用一次， 那么它可以准备并且保存这个命令的规划，把hostname作为参数传递。 规则应该这样写：
CREATE RULE computer_del AS ON DELETE TO computer
DO DELETE FROM software WHERE hostname = OLD.hostname;
现在看看这两种不同的删除。在下面情况：
DELETE FROM computer WHERE hostname = 'mypc.local.net';
对表computer, 使用索引(快速)进行扫描并且由触发器声明的查询也用索引进行扫描(同样快速)。 规则里多出来的查询是一个
DELETE FROM software WHERE computer.hostname = 'mypc.local.net'
AND software.hostname = computer.hostname;
因为已经建立了合适的索引，规划器将创建一个下面的规划
Nestloop -> Index Scan using comp_hostidx on computer -> Index Scan using soft_hostidx on software
所以在规则和触发器的实现之间没有太多的速度差别。
下面的删除希望删掉所有 2000 个hostname以old开头的计算机(记录)。 有两个可能的用于这个用途的查询。 一个是：
DELETE FROM computer WHERE hostname >= 'old'
AND hostname < 'ole'
规则增加的命令是：
DELETE FROM software WHERE computer.hostname >= 'old' AND computer.hostname < 'ole'
AND software.hostname = computer.hostname;
查询的规划将会是：
Hash Join
-> Seq Scan on software
-> Hash
-> Index Scan using comp_hostidx on computer
另一个可能的查询是：
DELETE FROM computer WHERE hostname ~ '^old';
它由规则增加执行规划是：
Nestloop -> Index Scan using comp_hostidx on computer -> Index Scan using soft_hostidx on software
这表明，规划器不能认识到表computer里的hostname的条件在 多个条件表达式以AND的方式组合在一起时同样可以用于software， 就像在用正则表达式的查询里一样。 触发器将在任何 2000 个要被删除的旧计算机里被调用一次， 结果是对computer的一次索引扫描和对software的 2000 次索引扫描。 规则的实现将会使用两个使用索引的命令来完成。 所以software表的实际大小决定了规则进行顺序扫描后是否仍然更快。 即使所有要使用的索引块都很快在缓冲里出现，执行 2000 个在 SPI 管理器上的查询仍然要花不少时间。
我们要看的最后一个查询是：
DELETE FROM computer WHERE manufacturer = 'bim';
同样，这也会导致从computer表里删除多行。 所以触发器同样会向执行器提交很多查询。 规则生成的命令将会是：
DELETE FROM software WHERE computer.manufacturer = 'bim'
AND software.hostname = computer.hostname;
但规则规划又将是对两个索引扫描的嵌套循环。 不过使用了computer的另外一个索引：
Nestloop -> Index Scan using comp_manufidx on computer -> Index Scan using soft_hostidx on software
在任何一种情况下，从规则系统出来的额外查询都或多或少与查询中涉及到的行数量相对独立。
概括来说，规则只是在它们的动作生成了又大又烂的条件连接时才比触发器有较大速度差异，这时规划器将失效。