社区
Java EE
帖子详情
听论坛大神说,做Java EE项目时候,数据库最好不用外键?
mervynhit
2012-10-01 06:30:35
而且在ORM配置时,最好不要做一对多,多对多关联,完全靠程序控制数据完整性,是不是这样啊,我有个朋友以前在公司做的JEE项目也是这样,表没有外键,我当时还嘲笑他们的方法很奇葩,现在我自己都迷茫了。
求指导?
...全文
989
15
打赏
收藏
听论坛大神说,做Java EE项目时候,数据库最好不用外键?
而且在ORM配置时,最好不要做一对多,多对多关联,完全靠程序控制数据完整性,是不是这样啊,我有个朋友以前在公司做的JEE项目也是这样,表没有外键,我当时还嘲笑他们的方法很奇葩,现在我自己都迷茫了。 求指导?
复制链接
扫一扫
分享
转发到动态
举报
AI
作业
写回复
配置赞助广告
用AI写文章
15 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
coooliang
2012-10-26
打赏
举报
回复
[Quote=引用 5 楼 的回复:]
刚工作就被老板洗脑了,说外键、触发器、存储过程一概不用。当时也怀疑,后来上网搜了好多东西,发现确实这样。
[/Quote]
存储过程不可能不用吧。。
dxqrr
2012-10-05
打赏
举报
回复
我现在的公司就没用外键,不过存储不用,这个不至于,存储过程会提高效率的吧
不关橙猫猫事的哦
2012-10-04
打赏
举报
回复
我们公司也没用外键,老大说影响性能,用程序控制就行了。。我之前的那家公司使用hibernate,也没配置一对多多对一的关系,到现在我还不知道inverse cascade怎样用。然后现在的公司用ibatis,估计再搞几个月hibernate就忘光了。。
碧海情天-赵亮
2012-10-04
打赏
举报
回复
其实一句话就概括了:理想化的设计和变化的现实情况之间还是有距离的。
任何事情,好处都伴随着弊端。
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]
其他几点还没有体会,但第四点确实已经体会到了...
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了。
liangtu
2012-10-01
打赏
举报
回复
如果数据量小,用外键没什么问题;数据量越大,越少用。
就好像用hibernate针对数据量少的情况是不错的,数据量一大就影响查询速度。
火龙果被占用了
2012-10-01
打赏
举报
回复
1:在大数量的情况下,使用外键约束会导致很差的性能。一般互联网应想都不要去想外键这种东西了,连表连接查询最好都不要使用
2:大数据量时进行表的水平切分,像外键约束、触发器、存储过程这些都是禁区
3:数据完整性是业务的需要,因此得由业务层的应用程序来控制
4:外键会导致表结构非常混乱,几乎是动都不能去动,一层套一层的外键约束,在表很多的情况下很可能会导致循环约束
Java
Web书城
项目
尚硅谷书城
项目
:自己整理的笔记以及全部实现过程,原理。 链接: 点击获取资源 提取码: ih2c 再次感谢尚硅谷,我爱尚硅谷!!!! 目录 第一阶段:对注册页面的信息进行验证: 第二阶段:用户管理模块 2.1、创建...
阿里
Java
面经大全(整合版)
1.上来问我
项目
用的框架,然后问我springmvc里面有的参数的设定,问的是细节,然后问我如果传的多个值是一个对象的属性,问我如何处理,我
说
直接在后端接收为对象就行了,然后突然问我http怎么传对象,这里有点不...
Java
菜鸟到大牛学习路线培训教程
主要分5个阶段:
Java
程序员->
Java
初级软件工程师->
Java
中级软件工程师->
Java
高级软件工程师->
Java
系统架构师,从头学到尾即可成为
大神
!成为架构师是爱好编程的程序员的最终目标! 第1阶段(
Java
程序员) -
Java
...
Java
面试题全集(下)
这部分主要是开源
Java
EE
框架方面的内容,包括Hibernate、MyBatis、Spring、Spring MVC等,由于Struts 2已经是明日黄花,在这里就不讨论Struts 2的面试题,如果需要了解相关内容,可以参考我的另一篇文章...
MySQL
数据库
MySQL
数据库
本章内容 关系型
数据库
基础 安装MySQL 管理
数据库
和表 用户和权限管理 函数,存储过程,触发器和事件 MySQL架构 存储引擎 服务器选项,系统和状态变量 优化查询和索引管理 锁和事务管理 日志管理 备份...
Java EE
67,550
社区成员
225,863
社区内容
发帖
与我相关
我的任务
Java EE
J2EE只是Java企业应用。我们需要一个跨J2SE/WEB/EJB的微容器,保护我们的业务核心组件(中间件),以延续它的生命力,而不是依赖J2SE/J2EE版本。
复制链接
扫一扫
分享
社区描述
J2EE只是Java企业应用。我们需要一个跨J2SE/WEB/EJB的微容器,保护我们的业务核心组件(中间件),以延续它的生命力,而不是依赖J2SE/J2EE版本。
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章