听论坛大神说，做Java EE项目时候，数据库最好不用外键？
而且在ORM配置时，最好不要做一对多，多对多关联，完全靠程序控制数据完整性，是不是这样啊，我有个朋友以前在公司做的JEE项目也是这样，表没有外键，我当时还嘲笑他们的方法很奇葩，现在我自己都迷茫了。

求指导?

------解决方案--------------------
1：在大数量的情况下，使用外键约束会导致很差的性能。一般互联网应想都不要去想外键这种东西了，连表连接查询最好都不要使用
2：大数据量时进行表的水平切分，像外键约束、触发器、存储过程这些都是禁区
3：数据完整性是业务的需要，因此得由业务层的应用程序来控制
4：外键会导致表结构非常混乱，几乎是动都不能去动，一层套一层的外键约束，在表很多的情况下很可能会导致循环约束
------解决方案--------------------
如果数据量小，用外键没什么问题；数据量越大，越少用。
就好像用hibernate针对数据量少的情况是不错的，数据量一大就影响查询速度。
------解决方案--------------------
1、所谓表的外键只不过是在数据库一级帮助你约束数据关系的完整性，加不加和业务处理毫无关系（不是说你加了外键你的技术就NB了呵呵）。加外键的确影响数据更新的效率，但到底影响多大就见仁见智了。我个人的倾向也是不加。
2、【在ORM配置时，最好不要做一对多，多对多关联，完全靠程序控制数据完整性】这句话不敢苟同，如果连1对多都不做了，还用hibernate干甚？如果是怕影响效率，用惰性加载就ok了。
------解决方案--------------------
其实一句话就概括了：理想化的设计和变化的现实情况之间还是有距离的。
任何事情，好处都伴随着弊端。

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

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

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