触发器正确用法

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

 

一、数据库完整性讨论

有许多同窗认为开发阶段不必创建外键约束，更不用创建检查约束，由于会影响单表数据写入作测试。

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

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

而后完整性约束包含主外键约束的，是数据反应现实世界真实状况的保证，若是没有完整性约束，数据多是无心义的，那么无心义的数据写入了也是无心义，测试也是无心义，测试经过的只是一段无心义但结果凑巧对了的代码。

 

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

 

二、触发器的做用

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

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

通常状况是用来保证数据完整性和安全性。

 

咱们知道能够给表中某个字段创建检查约束（check），有一种状况是检查约束作不到的。

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

 

咱们来看一个需求：

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

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

用户（用户id,用户名）

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

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

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

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

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

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

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