1：在大数量的情况下，使用外键约束会导致很差的性能。一般互联网应想都不要去想外键这种东西了，连表连接查询最好都不要使用
2：大数据量时进行表的水平切分，像外键约束、触发器、存储过程这些都是禁区
3：数据完整性是业务的需要，因此得由业务层的应用程序来控制
4：外键会导致表结构非常混乱，几乎是动都不能去动，一层套一层的外键约束，在表很多的情况下很可能会导致循环约束

如果数据量小，用外键没什么问题；数据量越大，越少用。
就好像用hibernate针对数据量少的情况是不错的，数据量一大就影响查询速度。

1、所谓表的外键只不过是在数据库一级帮助你约束数据关系的完整性，加不加和业务处理毫无关系（不是说你加了外键你的技术就NB了呵呵）。加外键的确影响数据更新的效率，但到底影响多大就见仁见智了。我个人的倾向也是不加。
2、【在ORM配置时，最好不要做一对多，多对多关联，完全靠程序控制数据完整性】这句话不敢苟同，如果连1对多都不做了，还用hibernate干甚？如果是怕影响效率，用惰性加载就ok了。

刚工作就被老板洗脑了，说外键、触发器、存储过程一概不用。当时也怀疑，后来上网搜了好多东西，发现确实这样。

数据库的设计之前往往是实体设计，实体之间的聚合关系我个人感觉还是建外键的好，毕竟从某种情况可以利用数据库的特性，而对于实体的复杂属性，就无需建立外键了，也不应该建立外键。

存储过程开始可以用用的。。。做过的项目没一个用外键的

IBM公司的产品里面自带的oracle数据文件，就使用外键。
所以说，没有什么银弹。

引用 2 楼  的回复:

1：在大数量的情况下，使用外键约束会导致很差的性能。一般互联网应想都不要去想外键这种东西了，连表连接查询最好都不要使用
2：大数据量时进行表的水平切分，像外键约束、触发器、存储过程这些都是禁区
3：数据完整性是业务的需要，因此得由业务层的应用程序来控制
4：外键会导致表结构非常混乱，几乎是动都不能去动，一层套一层的外键约束，在表很多的情况下很可能会导致循环约束

其他几点还没有体会，但第四点确实已经体会到了...

有外键的表往里插条数据就知道了

外键约束还是很有用的，实际应用中可以取舍

其实一句话就概括了：理想化的设计和变化的现实情况之间还是有距离的。
任何事情，好处都伴随着弊端。

1.量变会引起质变。在量上若没有清醒的判断区分，使用一些与性能与反比的技术就会搬起石头砸自己的脚。

2.计划没有变化快。需求会根据客观和主观变化而不断调整。牺牲灵活性带来的便利，在一段使用之后，积重难返，就会和需求变化产生矛盾。

实际上，对一些不是明显简单且数据量少的项目，在没做之前，其实是需要对各种技术选择方案做一些测试的，包括很多方面，数据压力是其中最常见的。根据项目情况，构造其能达到的极限数据量，对于开发者或者测试者来说，并不难。就算是比较有经验的老手，都不敢不做测试实验，而以自己的经验来为项目的成败负责。

我们公司也没用外键，老大说影响性能，用程序控制就行了。。我之前的那家公司使用hibernate，也没配置一对多多对一的关系，到现在我还不知道inverse cascade怎样用。然后现在的公司用ibatis，估计再搞几个月hibernate就忘光了。。

我现在的公司就没用外键,不过存储不用,这个不至于,存储过程会提高效率的吧

引用 5 楼  的回复:

刚工作就被老板洗脑了，说外键、触发器、存储过程一概不用。当时也怀疑，后来上网搜了好多东西，发现确实这样。

存储过程不可能不用吧。。