实际开发中，是否会在数据库表中设置外键？

      本科学习数据库的时候，书上明确的写了对于多对多关系必须要创建外键，可是最近在跟师兄做一个B/S架构的项目，发现所设计的数据库表虽然是多对多关系但并没有要求外键，查了一下之后才发现目前的大型系统中（尤其是互联网的大型项目）不会有外键这种东西，在这里总结一下以供今后学习。
原文地址
      设计数据库时是否采用外键取决于业务应用场景，以及开发成本，也就是说对于这个问题并没有绝对的答案。

1. 应用场景的比较 互联网行业应用不推荐使用外键： 用户量大，并发度高，为此数据库服务器很容易成为性能瓶颈，尤其受IO能力限制，且不能轻易地水平扩展；若是把数据一致性的控制放到事务中，也即让应用服务器承担此部分的压力，而引用服务器一般都是可以做到轻松地水平的伸缩；
   传统行业（软件使用人数可控）的可以使用外键。
2. 外键的性能问题
   1.数据库需要维护外键的内部管理；
   2.外键等于把数据的一致性事务实现，全部交给数据库服务器完成；
   3.有了外键，当做一些涉及外键字段的增，删，更新操作之后，需要触发相关操作去检查，而不得不消耗资源；
   4.外键还会因为需要请求对其他表内部加锁而容易出现死锁情况；

历史背景：
数据库的诸多设计，帐号，权限，约束，触发器，都是为 C/S 结构设计的，是以 C 端不可信做为假设前提的。B/S 模式安全边界前移到 web 服务层，应用与数据库之间是可信的，应用自行完成这些功能更加灵活。

总结：
在大型互联网项目中不使用外键，是为了系统的性能，但这并不代表没有实现实现表与关联表之间的数据一致性和更新，只不过是在业务层对此做了限制，确保由Service到Dao再到Service都是符合数据库规范的，与使用外键的作用是相同的，但这样做可以进一步提升系统性能。
在本科学习的时候，老师确实强调要写外键，但在实际开发中情况往往是除了主键和非空约束外，其他的都不要，主要通过程序来控制外键关联！因此，实践和理论还是有差别的，但有一点却是不变的，那就是无论理论还是实践都是用来为实际需求服务的，也就是说“怎么好怎么来，要因时制宜，灵活变通。”