我在大学时上数据库的课程，学的三个范式中有个第三范式就是专指的外键约束。但是出来工做之后第一次作数据库表设计的时候，组长大佬却让我在数据库中不要使用外键，改在代码中作相应处理。说得专业点，就是不要在数据库中使用物理外键，改成使用逻辑外键，即在代码中写相关的逻辑代替外键所起的做用。我今后便懂得了，解决实际的问题要从实际出发，不能照本宣科。数据库
外键的做用编程
1.外键能保证数据的完整性。在没有外键的状况下，数据库就不能强制进行引用完整性检查，若是在高一层没有进行正确的处理，则可能会致使数据出现不一致的状况。架构
2.外键能使表之间的关系变得清晰。若是数据库中缺乏外键，不了解表之间关系的人很难找到正确的关联表，这样可能会致使严重的数据库查询问题（关联错表、查错表）。框架
为何数据库能够没有外键数据库设计
既然外键有那么多好处，为何这里说设计数据库的时候能够不要外键呢，想做死嘛？可是世事无绝对的，这个世界也不是非黑即白的，不少时候人生只能随波逐流，跟着环境改变。意思就是说，数据库设计仍是要根据实际状况，其实有7个理由能够说明为何数据库能够没有外键。post
1.提升性能性能
在表上拥有活动的外键能够提升数据的质量，可是会影响插入、更新和删除操做的性能。由于在这些操做任务以前，数据库须要检查它是否违反数据完整性。这就是为何一些架构师和DBA彻底放弃外键的缘由。数据仓库和分析数据库尤为如此，这些数据仓库和分析数据库不以业务方法（一次一行）处理数据，而是批量处理数据。性能是数据仓库和商业智能的一切。测试
2.方便旧数据的导入设计
许多数据库在设计的时候须要考虑导入来自旧数据库的数据的因素。这些数据可能对数据的质量和完整性没有那么严格，为了可以容纳旧的脏数据，架构师有两个选择，一是清理和转换旧的历史遗留数据（昂贵代价，须要人工去编制数据）；二是放弃在数据库级别上强制执行参照完整性。哪一个方法更好更节约成本更高效，我相信已经不言而喻了。对象
3.方便全表的从新加载
一些数据库，如数据仓库，分段或接口数据库，须要常常从外部从新加载数据。就像你本地的测试数据库须要从生产环境的正式数据库从新加载数据同样。这可能会致使从新加载数据时数据不一致（在父表为空的状况下，子表可能已经装满）。虽然能够经过在从新加载数据的时候禁用外键来绕过这个问题，然而这却引入了额外的逻辑和复杂性，以及另外一个失败点，对性能有负面影响。
4.将外键起的做用交给更高层次的框架完成
一些应用程序使用编程框架，在物理数据库之上建立另外一个逻辑层，开发人员不须要编写插入或更新语句来修改数据，而是调用提供的API在后台执行全部操做。ORM（对象关系映射）框架好比Hibernate就是这种状况，这些框架负责维护参照完整性，并与RDBMS一块儿建立更高级别的数据库引擎。
5.方便跨数据库
在一些大型系统，可能会有不少个数据库。好比说A表在A数据库，B表在B数据库，你想在A表和B表之间建立外键是不可能的。固然你可能会说A表和B表要建立外键就把A表和B表放在一个数据库里面啊，可是我偏不，嘿嘿。
6.节约一些工做成本（偷懒/提升效率）
在建立数据库的时候，若是要存储数据，最低限度是要建立一些表和一些字段。可是建立一些保证数据一致性的结构却不是必须的工做，好比外键等约束。这些工做须要人力和时间成本，可是却没有带来直接的好处。所以不少架构师和DBA都选择忽略掉这一部分。
7.让你在团队里变得不可替代
在现实的社会中，不少人都但愿被须要和不可被替代。若是数据库表的设计者是你且只有你，那么表之间的关系就只有你知道，别人要知道表之间的关系就只能经过你，你就变成了不可替代的那我的了。固然在现实中是不可能的，数据库设计都是要留存的，好比说PDM；你也不可能成为不被替代的那我的。没有错，现实就是那么残酷。
"世界上没有谁是不可替代的，一我的离开了，立刻就会有另一我的取代他的位置。"