触发器正确用法

关键字：架构设计 软件质量保证 数据库完整性

 

1、数据库完整性讨论

有许多同学认为开发阶段没必要建立外键约束，更不用建立检查约束，因为会影响单表数据写入做测试。

这个想法是非常错误的，不规范的，不专业的。

首先影不影响测试是无稽之谈，说明这类同学开发时不会写单元测试，通过野路子来测试，质量不保。

然后完整性约束包含主外键约束的，是数据反应现实世界真实情况的保证，如果没有完整性约束，数据可能是无意义的，那么无意义的数据写入了也是无意义，测试也是无意义，测试通过的只是一段无意义但结果凑巧对了的代码。

 

所以严格设计数据库，除了遵循范式之外，完整性约束是必须的。

 

2、触发器的作用

很多时候代码更加面向对象了，要求业务逻辑都能在代码的业务逻辑层体现，是不推荐将业务逻辑分散到代码、数据库等多处，集中写，集中管理。

所以触发器和存储过程将会更少地使用，那么触发器在当今代码界还有什么作用呢？

一般情况是用来保证数据完整性和安全性。

 

我们知道可以给表中某个字段建立检查约束（check），有一种情况是检查约束做不到的。

不能因为难做，就放弃了完整性的控制，检查约束做不到，就用触发器（插入性能损失，怕什么！触发器是可以停用的，不能将锅都甩给性能）。

 

我们来看一个需求：

现在有一个游戏，然后游戏策划搞了一次活动推出一个礼包，这个礼包只允许在活动期间充值5000元以上的用户才能下单购买，活动期间等于礼包上架时间到下架时间，那么除了在业务代码中下单前检查用户在活动期间充值情况以外，如何在数据库完整性设计中体现呢？

---------------------------------------------

用户（用户id,用户名）

用户充值(用户id,充值金额,充值时间)

礼包订单(订单id,用户id,礼包id)

礼包(礼包id,礼包名,上架时间,下架时间,价格)

---------------------------------------------

通常，我们在下订单的时候，写入礼包订单表记录，然后有外键约束的存在，验证了礼包、用户，那么如何验证用户的充值呢？

没办法使用检查约束吧，因为充值金额和礼包上下架时间并不包含在礼包订单里。

这个时候用触发器就是正解了。