67,535
社区成员
发帖
与我相关
我的任务
分享听论坛大神说，做Java EE项目时候，数据库最好不用外键？
而且在ORM配置时，最好不要做一对多，多对多关联，完全靠程序控制数据完整性，是不是这样啊，我有个朋友以前在公司做的JEE项目也是这样，表没有外键，我当时还嘲笑他们的方法很奇葩，现在我自己都迷茫了。
求指导?
求指导?
...全文
请发表友善的回复…
发表回复
coooliang 2012-10-26
- 打赏
- 举报
[Quote=引用 5 楼 的回复:]
刚工作就被老板洗脑了，说外键、触发器、存储过程一概不用。当时也怀疑，后来上网搜了好多东西，发现确实这样。
[/Quote]
存储过程不可能不用吧。。
刚工作就被老板洗脑了，说外键、触发器、存储过程一概不用。当时也怀疑，后来上网搜了好多东西，发现确实这样。
[/Quote]
存储过程不可能不用吧。。
dxqrr 2012-10-05
- 打赏
- 举报
我现在的公司就没用外键,不过存储不用,这个不至于,存储过程会提高效率的吧
javabugsmaker 2012-10-04
- 打赏
- 举报
我们公司也没用外键，老大说影响性能，用程序控制就行了。。我之前的那家公司使用hibernate，也没配置一对多多对一的关系，到现在我还不知道inverse cascade怎样用。然后现在的公司用ibatis，估计再搞几个月hibernate就忘光了。。
碧海情天-赵亮 2012-10-04
- 打赏
- 举报
其实一句话就概括了：理想化的设计和变化的现实情况之间还是有距离的。
任何事情，好处都伴随着弊端。
1.量变会引起质变。在量上若没有清醒的判断区分，使用一些与性能与反比的技术就会搬起石头砸自己的脚。
2.计划没有变化快。需求会根据客观和主观变化而不断调整。牺牲灵活性带来的便利，在一段使用之后，积重难返，就会和需求变化产生矛盾。
实际上，对一些不是明显简单且数据量少的项目，在没做之前，其实是需要对各种技术选择方案做一些测试的，包括很多方面，数据压力是其中最常见的。根据项目情况，构造其能达到的极限数据量，对于开发者或者测试者来说，并不难。就算是比较有经验的老手，都不敢不做测试实验，而以自己的经验来为项目的成败负责。
任何事情，好处都伴随着弊端。
1.量变会引起质变。在量上若没有清醒的判断区分，使用一些与性能与反比的技术就会搬起石头砸自己的脚。
2.计划没有变化快。需求会根据客观和主观变化而不断调整。牺牲灵活性带来的便利，在一段使用之后，积重难返，就会和需求变化产生矛盾。
实际上，对一些不是明显简单且数据量少的项目，在没做之前，其实是需要对各种技术选择方案做一些测试的，包括很多方面，数据压力是其中最常见的。根据项目情况，构造其能达到的极限数据量，对于开发者或者测试者来说，并不难。就算是比较有经验的老手，都不敢不做测试实验，而以自己的经验来为项目的成败负责。
dlpzgr 2012-10-04
- 打赏
- 举报
外键约束还是很有用的，实际应用中可以取舍
wnf2009 2012-10-03
- 打赏
- 举报
存储过程开始可以用用的。。。做过的项目没一个用外键的
zclih2 2012-10-03
- 打赏
- 举报
有外键的表往里插条数据就知道了
yktd26 2012-10-03
- 打赏
- 举报
[Quote=引用 2 楼 的回复:]
1：在大数量的情况下，使用外键约束会导致很差的性能。一般互联网应想都不要去想外键这种东西了，连表连接查询最好都不要使用
2：大数据量时进行表的水平切分，像外键约束、触发器、存储过程这些都是禁区
3：数据完整性是业务的需要，因此得由业务层的应用程序来控制
4：外键会导致表结构非常混乱，几乎是动都不能去动，一层套一层的外键约束，在表很多的情况下很可能会导致循环约束
[/Quote]
其他几点还没有体会，但第四点确实已经体会到了...
1：在大数量的情况下，使用外键约束会导致很差的性能。一般互联网应想都不要去想外键这种东西了，连表连接查询最好都不要使用
2：大数据量时进行表的水平切分，像外键约束、触发器、存储过程这些都是禁区
3：数据完整性是业务的需要，因此得由业务层的应用程序来控制
4：外键会导致表结构非常混乱，几乎是动都不能去动，一层套一层的外键约束，在表很多的情况下很可能会导致循环约束
[/Quote]
其他几点还没有体会，但第四点确实已经体会到了...
showgood119 2012-10-03
- 打赏
- 举报
IBM公司的产品里面自带的oracle数据文件，就使用外键。
所以说，没有什么银弹。
所以说，没有什么银弹。
telent 2012-10-02
- 打赏
- 举报
数据库的设计之前往往是实体设计，实体之间的聚合关系我个人感觉还是建外键的好，毕竟从某种情况可以利用数据库的特性，而对于实体的复杂属性，就无需建立外键了，也不应该建立外键。
rockets311 2012-10-02
- 打赏
- 举报
刚工作就被老板洗脑了，说外键、触发器、存储过程一概不用。当时也怀疑，后来上网搜了好多东西，发现确实这样。
NewMoons 2012-10-01
- 打赏
- 举报
1、所谓表的外键只不过是在数据库一级帮助你约束数据关系的完整性，加不加和业务处理毫无关系（不是说你加了外键你的技术就NB了呵呵）。加外键的确影响数据更新的效率，但到底影响多大就见仁见智了。我个人的倾向也是不加。
2、【在ORM配置时，最好不要做一对多，多对多关联，完全靠程序控制数据完整性】这句话不敢苟同，如果连1对多都不做了，还用hibernate干甚？如果是怕影响效率，用惰性加载就ok了。
2、【在ORM配置时，最好不要做一对多，多对多关联，完全靠程序控制数据完整性】这句话不敢苟同，如果连1对多都不做了，还用hibernate干甚？如果是怕影响效率，用惰性加载就ok了。
liangtu 2012-10-01
- 打赏
- 举报
如果数据量小，用外键没什么问题；数据量越大，越少用。
就好像用hibernate针对数据量少的情况是不错的，数据量一大就影响查询速度。
就好像用hibernate针对数据量少的情况是不错的，数据量一大就影响查询速度。
火龙果被占用了 2012-10-01
- 打赏
- 举报
1：在大数量的情况下，使用外键约束会导致很差的性能。一般互联网应想都不要去想外键这种东西了，连表连接查询最好都不要使用
2：大数据量时进行表的水平切分，像外键约束、触发器、存储过程这些都是禁区
3：数据完整性是业务的需要，因此得由业务层的应用程序来控制
4：外键会导致表结构非常混乱，几乎是动都不能去动，一层套一层的外键约束，在表很多的情况下很可能会导致循环约束
2：大数据量时进行表的水平切分，像外键约束、触发器、存储过程这些都是禁区
3：数据完整性是业务的需要，因此得由业务层的应用程序来控制
4：外键会导致表结构非常混乱，几乎是动都不能去动，一层套一层的外键约束，在表很多的情况下很可能会导致循环约束
