在DB2 UDB中使用SQL过程语言来操作触发器

测试规则
先测试业务规则 1，我们将插入两份来自于 Nancy 的饰品订单。这位客户的赊购最高限额仅为 $100，因此第一份订单被成功插入，而第二份则操作失败。（每份订单的价格均为 $90。）

Insert into orders_t values (nextval for ord_seq, 1, 1, 9, 10.0, 'ENDING')
Insert into orders_t values (nextval for ord_seq, 1, 1, 9, 10.0, 'ENDING')

我们可以在前面操作的基础上测试业务规则 2。鉴于订单的有效状态转换（前面已提到），状态为“PENDING”的订单可转换为“SHIPPED”。一旦订单物品已经发送，就不能被取消了。下面的第一个更新操作可以成功，但第二个将无法通过。

Update orders_t set status='HIPPED' where order_id=1
Update orders_t set status='ANCELLED' where order_id=1

我们只需试图去删除刚才插入的订单就可以测试业务规则 3。下面的删除语句将失败，因为该订单的状态不是“CANCELLED”。而且由于前面的这个触发器触发失败，用于记录删除操作的 AFTER DELETE 触发器也不会被激活。

Delete from orders_t where order_id=1

如果要测试这个用于记录删除操作的触发器，我们可以插入一份不超过 Nancy 最高赊购限额的订单，然后取消并删除它。

Insert into orders_t values (nextval for ord_seq, 1, 1, 1, 10.0, 'PENDING')
Update orders_t set status='CANCELLED' where order_id=(prevval for ord_seq)
Delete from orders_t where order_id=(prevval for ord_seq)
Select * from delete_log_t

性能技巧

* BEFBEFORE 触发器应该用于修改用户输入的值或用于生成新值，如生成主键。在 AFTER 触发器中试图修改转换表中的行更为复杂。

* DB2 是一个功能强大的关系引擎。然而，目前它并没有优化过程逻辑（控制）语句和其他 SQL 语句。

例如 verify_credit 触发器也可以改写成下面这样：

1 : CREATE TRIGGER verify_credit
2 : NO CASCADE BEFORE INSERT ON orders_t
3 : REFERENCING NEW AS n
4 : FOR EACH STATEMENT MODE DB2SQL
5 : WHEN ((SELECT SUM(price * quantity) FROM orders_t
6 :       WHERE cust_id = n.cust_id
7 :         AND status NOT IN ('COMPLETED', 'CANCELLED'))
8 :      + n.price * n.quality
9 :     > (SELECT credit FROM customer_t WHERE cust_id=n.cust_id))
10: SIGNAL SQLSTATE '80000' ('Order Exceeds credit line')

当你需要比较新值与旧值时，对于更新来说，最好选用 FOR EACH ROW 触发器，而不是 FOR EACH STATEMENT 触发器。使用 FOR EACH ROW 触发器可以获得更好的性能，因为每一行都包含用于比较的值，即可完成触发器的操作，而不需要使用存储在转换表中的所有新值和旧值。

其他技巧

* 支持 WHILE 循环。
* GET DIAGNOSTICS <var : int> = ROW_COUNT 可用于确定在触发器主体中最近调用的 update，delete 或 insert 语句影响了多少行记录。
* 不支持 SELECT .... INTO 语法。要将多列属性值传给多个变量应使用 use SET (x,y) = (SELECT x_col, y_col FROM mytable)。
* 避免使用递归触发器。递归触发器是指该触发器会被自身主体中相同的语句激活。例如，如果我们在表 mytable 上定义一个 DELETE 触发器，而其主体中也包含一个 mytable 上的DELETE 语句，这就是一个递归触发器。若不小心编码，就会产生问题。即使需要用到递归，也应限于使用单个迭代。
* 如果在一个表上定义多个触发器（也就是说，两个 BEFORE INSERT 触发器被定义），他们将按照被创建的次序来被执行。当然，BEFORE 触发器总是在 AFTER 触发器之前被激活而不必考虑其创建次序。表的其他约束条件（如主/外键约束，唯一性约束以及检查约束）同样会在 BEFORE 触发器之后，AFTER 触发器之前被检查。

结束语
触发器对于实施业务规则十分有效，而这些业务规则恰恰是数据库应用程序的中心。