江苏龙网

  1. 首页 > 生活 > >

Hibernate一对多，多对多...建立的表关联好用么，有没有人觉得这样的使用方法其实是个坑

长期和新手交流，hibernate 实体关联，最大的缺点就是误让新手觉得这就是加载数据的方式。。我写几条自认为的 Hibernate 最佳实践，欢迎大家做补充：除非必须，不要乱加关联不要使用级联双向关联要谨慎，能不用就不用主从关系要分明，不要颠倒实体关系要在实体中保持一致，而非在业务方法中重复出现实体有关联时，批量操作不要用 HQL，即便使用 HQL, 也要观察是否达到目的，如未达到目的，需要进行语句排序调优读写操作不要共用同一个实体实体关联中懒加载要默认禁用，需要 eager 加载时通过 hql 显式指定不需要触发 select 操作时，尽量使用 load 加载动态查询使用 Criteria 更方便只对频繁查询的只读数据开启二级缓存和查询缓存把 FlushMode 设置为 ALWAYS，防止写操作前的数据更改没有反馈到数据库，最然作者不推荐这么干，但默认的 AUTO 的确存在风险仅查询实体的某些属性时，可以这么干： \u0026#39;select new Entity(id, someField) from Entity\u0026#39;其他。。此外，也可以参考我的其他回答：会计转行从事IT，如何在一年时间内全职学习？spring有什么缺点吗？ - Java EE面试官会问关于spring的哪些问题？ - Javahibernate没有维护表间关系的中间表吗？ - JavaJpaDaoSupport的用法是怎么样的？ - Night Silent 的回答使用hibernate却完全不使用表关联查询，这是基于什么原因考虑？ - Springhibernate怎样更新两层一对多的实体，就是父＝》子＝》孙子，实体里有去孤子的注解。更新不到孙子？ - Night Silent 的回答hibernate没有维护表间关系的中间表吗？ - Night Silent 的回答我是否应该为了项目尽快学习spring?（长文） - Night Silent 的回答hibernate怎么调用mysql中的year(),month(),concat()等函数？ - Night Silent 的回答更多，可以关注我，随时获取最新回答JAVA 交流群，群号：151280557，二维码如下，（非自学勿扰）Hibernate一对多，多对多...建立的表关联好用么，有没有人觉得这样的使用方法其实是个坑

关于群的说明：长期以来，本群饱受各种培训机构、群宣水军、拿来主义者侵扰，为保持本群的技术氛围，本群入群方式修改为付费入群已经在群内的各位成员，请珍惜这个平台，一旦违反群规总是讨论和 Java 无关话题的，将被清理出群，再次进群，你只能付费，不守规矩是有代价的新入群的朋友，请先查阅群公告，了解下群规，入群后，欢迎有准备的提问，拒绝拿来主义入群所需费用，会被充当群费如果有朋友觉得本群/本篇文章帮到了你，也可以联系我（Q或私信），为本群捐赠群费，我会在公告里向大家公示数额及用途群费用途：为大家合购教程、为群续费、由我牵头做一些特定的事情（投票决定）等等再次重申：培训机构、群宣水军、拿来主义者，请自觉远离写在最后如果我的回答帮到了你，可以点赞同来支持我，也可以分享让更多需要帮助的人看到。
■网友
剔除楼主及答主情绪化的部分之后再分析的个人想法：确实是个坑， 也确实碰到很多题主说的问题，对级联数据的查询很方便， 上手快，但很容易造成循环查询，实际对程序员的开发能力有更高的要求。并发上锁只能在WEB程序里写，DB本来处理得很好的并发和锁的功能发挥不出来。复杂查询还是要写SQL语句或者存储过程。更新数据需要先查询出来再update, 这个一般都会加缓存，查询会从缓存里找， 不建立DB连接再查询，只update时才连接更新。一般说某个东西特别优秀的时候， 一般也默认了只局限于场景下。跳出这个场景就不好说了。
■网友
@蒋定坤@Alice 薇Joo最后的最后补充一些东西，借助“父子关系”讨论“中间表”存在的意义：在传统的数据建模中，允许为 Null 值的外键被认为是一种不好的实践。简单地说，数据库的外键关联所描述的最严格与最精准的事物关系应该是像“子-父”这样的单向多对一关系，也即，“子”必有“父”！而反方向的一对多的关系并不是其所能准确描述，原因就是“父”未必有“子”，所以从这个角度上说，使用【关联表】描述单向一对多是更加贴切的。为什么单向一对多(one-to-many)的映射要使用关联表？首先必须明确，一对一，一对多或者多对多都是【领域对象间】的关系，它们体现的是【业务层面】上各种事物之间的对应关系。这些对应关系与数据库上的【外键】关联是有【本质区别】的。但是当我们需要持久化这些数据时，又必须要把它们之间的这些关系以数据库方式保存起来，或者说是以数据库的方式对这些关系进行【模拟】。很显然，可供我们使用的方式无非就是外键关联和关联表。在所有对象关系中双向一对多也就是最最典型的“父子关系”使用外键关联是最贴切的！（注意，严格来说父子关系和双向一对多多对一关系是有一点差别的，那就是父子关系中要求子是一定有父的，而单向多对一中并没有明确要求一方是一定存在的，也就是说虽然领域对象之间存在一对多+多对一的关系，但是他们之间可以存在：【有许多小朋友没有父亲】）外键关联是两张表级别上的关联关系，这里有一个暗含的要求，那就是两张表的全部记录应该都满足这种约束才对（像在父子关系中，子一定有父一样！）。虽然这不是必须的。因为一旦我们允许【外键列为空】就会使得一些数据可以不受此外键约束，这于我们设置外键关联的初衷就背道而驰了。从一对多的语义上来看，它只期望从单端能够找到一组多端对象，【至于多端对象是不是都有一个对应的单端对象，是不再其关心或者表述范围之内的】。显然，要实现这种语义，必须置多端对象的外键为可空，来放宽于约束。从数据库设计的角度来看，外键为空是一种不好的设计，而使用关联表则可以避开这个问题。我们可以看到关联表允许我们只是对两表之间的【“部分”】数据间的关系进行表达。它们这种关系并不是表级别的，也就是说【并不是每条记录都有这种关系】，这比使用允许外联列为空的外键约束要自然和合理。由此我想，是不是对于单向多对一(many-to-one)来说，如果它对应的那个one不是必须有的时候，那我们是不是也不应该使用外键关联呢？我想答案是肯定的。再简明的把这个问题描述一下：因为单向一对多关系中对many方与one方之间的关系没有相关的描述，many方可能有对应的one方也可能没有，在这种情况下使用外键约束是不合适的。而双向一对多如果不能确定他们之间是严格的父子关系（产品迭代，为增强用户体验，需求有变更），在这种情况下使用外键约束也是不合适的。而使用关联表的好处就在于可以“规避”这个问题，也就是不正面回应这个问题。因为单向一对多关系本身就不关心这个问题。产品开发初期，双向一对多使用关联表能灵活的应对需求变更。现在公司做产品用HIBERNATE做持久层方案的还有么？


推荐阅读


上一篇：为啥阿里移动互联网表现不佳

下一篇：IT妹子该怎么样护肤呢