目标：简化数据库架构
一些开发人员不推荐使用引用完整性约束，可能不使用外键的原因有一下几点：
1、数据更新有可能和约束冲突；
2、当前的数据库设计如此灵活，以至于不支持引用完整性约束；
3、数据库为外键建立的索引会影响性能；
4、当前使用的数据库不支持外键。比如MySQL的MyISAM存储引擎，或者比SQLite3.6.19早的版本；
5、定义外键的语法并不简单，还需要查阅。
反模式：无视约束，即不使用约束
省略外键约束能使得数据库设计更加简单、灵活，或者执行更加高效，但是你不得不在其他方面付出相应的代价，
必须增加额外的代码来手动维护引用完整性。
1、假设无暇代码：要避免在没有外键约束的情况下产生引用的不完整状态，需要再任何改变生效前执行额外的Select查询，
以此来确保这些改变不会导致引用错误。比如在查询一条记录之前，需要检查对应的被引用记录是否存在。
2、检查错误：开发人员使用外部脚本来检查错误的数据。
3、修改代码时，无法保证系统中的所有部分都被同时修改。
4、可能有些用户直接操作了数据库，修改或删除被引用的字段值，导致其他表引用发生未知错误；
而且你不能确定所有的应用程序或者脚本在访问数据库时所做的操作都是正确合理的。
5、当你Update更新一条被其他记录依赖的记录时，在没有更新父记录前，你不能更新子记录，
而且也不能在更新父记录前更新子记录。你需要同步执行两边的更新，但是使用2个独立的更新语句是不显示的。
如何识别反模式：当出现以下情况时，可能是反模式
1、我要怎么写这个查询来检查一个值是否没有被同时存在2张表中？（通常这样的需求是为了查找那些孤立的行数据）
2、有没有一种简单的方法来判断在一张表中的数据是否也在第二张表中存在？
（这么做是用来确认父记录切实存在。外键会自动完成这些，并且外键会使用这父表的索引尽可能的高效完成）
3、有人说不要用外键，外键影响数据库效率。
合理使用反模式：
如果数据库产品不支持外键约束功能，则不得不使用别的方法来保持引用完整性，比如使用监控脚本。
同样也存在一些极度灵活的数据库设计，外键无法用来表示其对应的关系。
解决方案：声明约束
1、通过使用外键来确保应用完整性；
使用约束时：（1）数据库本身会拒绝所有不合理的改变，无论这个改变是通过什么方式造成的。
（2）能够避免编写不必要的代码，同时还能确保一旦修改了数据库中的内容，所有的代码依旧能够用同样的方式执行。
（3）外键的特性：级联更新，比如：On Update Cascade、On Delete Restrict等。
在执行更新和删除2个操作中的任意1个是，数据库都会自动修改多张表中的数据，
外键的引用状态在操作之前和之后都保持完好。
2、外键约束的确需要多那么一点额外的系统开销，但相比于其他的一些选择，外键确实更高效一点：
（1）不需要在更新或删除记录前执行Select检查；
（2）在同步修改时不需要再锁住整张表；
（3）不再需要执行定期监控脚本来修正不可避免的孤立数据。
SQL反模式，系列学习汇总