1、数据库完整性讨论
有许多同学认为开发阶段没必要建立外键约束，更不用建立检查约束，因为会影响单表数据写入做测试。
这个想法是非常错误的，不规范的，不专业的。
首先影不影响测试是无稽之谈，说明这类同学开发时不会写单元测试，通过野路子来测试，质量不保。
然后完整性约束包含主外键约束的，是数据反应现实世界真实情况的保证，如果没有完整性约束，数据可能是无意义的，那么无意义的数据写入了也是无意义，测试也是无意义，测试通过的只是一段无意义但结果凑巧对了的代码。
所以严格设计数据库，除了遵循范式之外，完整性约束是必须的。
2、触发器的作用
很多时候代码更加面向对象了，要求业务逻辑都能在代码的业务逻辑层体现，是不推荐将业务逻辑分散到代码、数据库等多处，集中写，集中管理。
所以触发器和存储过程将会更少地使用，那么触发器在当今代码界还有什么作用呢？
一般情况是用来保证数据完整性和安全性。
我们知道可以给表中某个字段建立检查约束（check），有一种情况是检查约束做不到的。
不能因为难做，就放弃了完整性的控制，检查约束做不到，就用触发器（插入性能损失，怕什么！触发器是可以停用的，不能将锅都甩给性能）。
我们来看一个需求：
现在有一个游戏，然后游戏策划搞了一次活动推出一个礼包，这个礼包只允许在活动期间充值5000元以上的用户才能下单购买，活动期间等于礼包上架时间到下架时间，那么除了在业务代码中下单前检查用户在活动期间充值情况以外，如何在数据库完整性设计中体现呢？
---------------------------------------------
用户（用户id,用户名）
用户充值(用户id,充值金额,充值时间)
礼包订单(订单id,用户id,礼包id)
礼包(礼包id,礼包名,上架时间,下架时间,价格)
---------------------------------------------
通常，我们在下订单的时候，写入礼包订单表记录，然后有外键约束的存在，验证了礼包、用户，那么如何验证用户的充值呢？
没办法使用检查约束吧，因为充值金额和礼包上下架时间并不包含在礼包订单里。
这个时候用触发器就是正解了。