在中使用过程语言来操作物业

测试规则

先测试业务规则 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 语句。

力图发现下一个苏宁电器。寻找那些具备行业整合者、领先者潜质的企业。 10年内成为下一个苏宁 例如 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 = st_id

7 : AND status NOT IN (\'COMPLETED\', \'CANCELLED\'))

8 : + ice * ality

9 : (SELECT credit FROM customer_t WHERE cust_id=st_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 触发器之前被检查。

结束语

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