8
回答
实际工作中,一般不使用Hibernate的1对多关系?
终于搞明白,存储TCO原来是这样算的>>>   

总结:

    实际工作中Hibernate的OneToMany还是挺常用的,毕竟不是所有项目都会有1:1千万的情况。

但如果数据量达到了某种程度,如大大菠萝所说,1:1百万就很慢了。这时候,你就需要写HQL进行查询。

看具体情况而定,这需要搞需求分析的哥们来决定。

谢谢大家的回答。

------------------------------------------------------------------------------------------------  

  听到有人说,在工作中,一般不使用1对多的关系映射,只使用多对1。为什么呢?

    理由是:如果未来的表数据出现一条记录对应一千万条记录的情况,使用1对多,有可能会造成系统的崩溃。哪怕有延迟加载,但也有可能有新入职的不十分了解逻辑的员工去主动获取‘多’方的数据。

    听上去很有点道理。可是,个人并未遇到过这样的情况。在网上也并没有找到类似看法的帖子。

    所以,来问问大家,你们在工作中会使用1对多吗?你对这种看法又是什么个意见?赞同 or 反对?

举报
itwriter
发帖于4年前 8回/2K+阅
共有8个答案 最后回答: 4年前
恩。最近也思考过这个问题。我是用的懒加载。不过在一取多的时候。先用HQL查出来需要的“多”的一方的 数据,然后在set给1的一方。不知道还有没有其他方法。一对多不只是部门跟员工的问题,比如铁道部的车辆运行记录什么的。这样的例子很多。其实上百万如果实时加载的话就很慢了。特别是不是单纯的一对多的关系。比如一对多。多的一方再是一对多~我现在的业务就有这种情况。
--- 共有 2 条评论 ---
__loong回复 @itwriter : 恩。暂时我是这么做的 因为找不到更好的办法了。。希望如果你找到更好的解决办法 分享一下@我一下 呵呵~ 4年前 回复
itwriter就是说,也会使用@OneToMany,但具体要用到Set的数据时,再显式地手写HQL查询数据么。 4年前 回复
这两个关系有区别吗?由哪方来为维护数据才会产生很大的效率问题。
--- 共有 2 条评论 ---
迷途蜗牛回复 @itwriter : 你说的是典型的N+1问题,可以从懒加载和二级缓存上解决。我通常都用的双向关系,然后在查询时注意效率。 4年前 回复
itwriter没区别? 多对1的话,最多多查1条记录。 如果1对多——如果是1对1千万,那就好玩了。 4年前 回复
who说的用到的,看数据量决定,因为开发的时候,时间其实是最重要的,页面响应速度能过的去就不成问题!
--- 共有 1 条评论 ---
itwriter开发测试时候是没问题——就怕以后运行起来后,数据量多了,就产生问题了。 4年前 回复
Hibernate 就是喜欢偷偷摸摸干一些事  不了解的人当然不知道数据量大了之后的隐患  所以有人还是喜欢mybatis 这些的 明确知道做了哪些事 
不过我想既然用了hibernate 还是用的好, 写的时候多看控制台到底做了哪些事
完全没有道理,订单和订单明细,典型的一对多,你硬要反过来?一千万条记录你不加查询条件就直接用怪谁?入门的小白也知道要加个分页。

引用来自“huan”的答案

完全没有道理,订单和订单明细,典型的一对多,你硬要反过来?一千万条记录你不加查询条件就直接用怪谁?入门的小白也知道要加个分页。
你大概误会我的意思了。
这里的1对多指的是Hibernate的OneToMany标签。如:
@Entity
public class Dept {


@Id
@GeneratedValue(strategy=GenerationType.IDENTITY)
private int deptid;
private String dname;
private String location;

@OneToMany
private Set<Employee> emps = new HashSet<Employee>();
……
这里面怎么加分页和查询条件我确实不懂,请指教。
不过,如果这个问题像您说的如此简单,Hibernate就不会有1+n的问题了。
--- 共有 2 条评论 ---
itwriter回复 @魔力猫 : 这只是个说明用的测试用例,当然不是实际例子。 毕竟,我也没真遇到过1:1千万的实际情况。 现在只是想问问大家,如果遇到类似的情况该如何解决。 4年前 回复
魔力猫有问题吗?如果正常情况下一个部门有多少职员呢?几十个就到头了吧。如果你非要说这个部门几千个职员,那么我要考虑的不是类设计而是这家企业破产前能不能给钱了。延迟加载、缓存等等都是用来解决面向对象和数据库表的不匹配的问题,合理使用,绝大多数问题都是可以解决的。 4年前 回复
顶部