@mschultz 哥们看一下我单独发的主题，虽然现在这种算法问题很大，但你希望那种方式是不可能存在的。

有保修跟没保修，那是天壤之别。官翻机属于新机系列，资源机属于二手系列。就算那个二手商说得话是真得，也别去傻乎乎的去买资源机。

@xmumiffy 林北这回有闲功夫，就给你说说年终奖单独计税的优惠点在哪里。https://ex.noerr.eu.org/t/1014190

@xmumiffy #70 所以你是并不理解，个税改成按年后，年终奖单独计税的优惠点在哪里了？啥都不懂在这里狂按键盘。

@xmumiffy #63 要搞「嗟，来食」吗。先来考考你，年终奖单独计算是哪里优惠。来看看你是真赵还是精赵。

不如直接把公司所有业务都仍虚拟机里面。

你怎么能理解到国外都是公有 SaaS ，难道微软给国防部的云（假如没被亚马逊搞真拿下订单的话），会是公有云上的租户，那铁定是私有云。

这个问题的核心关键不是公有跟私有，而是你到底是部署来给谁用的，给内部人用的那就私有部署，给公众用的那就从公有云上租

@PrinceofInj #54 仔细看看你上面两楼的。你年纪越大越会发现指定规则的人并不一定都是学习好的。

@Nosub #56 作者信息，是「文章」的属性，它来自于「用户」，但与「用户」不存在实体关联关系。换个更直白的说法，文章的作者姓名，跟用户的名称，通过用户 ID 能映射，但他们不是同一个值。如果再仔细看，用户名称可变更，但作者姓名是不可变更的，它们连等值映射都做不了。你的实体关联关系是错误的。

请注意，上面说的是实体关联关系，即 Entity-Relation ，这是数据库设计的概要模型阶段，与 ORM 、DDD 都没关系。

当把 ER 弄明白之后，在看「查询文章列表，其中要带上作者信息」这个查询，那就根本不存在任何性能问题，因为这是单表查询。当然这个不是没有其他付出的，需要额外处理「文章」的 userId 、authorName 、authorAvatar ，跟 「用户」的 id 、name 、avatar 之间的一致性问题。不过这个原本就是之前漏掉的业务功能，严格的说也不算是额外付出。处理起来也不是那么麻烦：
Post.userId - User.id 这是不变量，只需要自然保存即可；
Post.authorName - User.name ，实际业务上，这里已经是不相干的俩属性了，根本无需同步，如果功能上设计成需要同步的，见下面 avatar 的同步处理；
Post.authorAvatar - User.avatar ，需要 User 修改 avatar 的时候，利用观察者模式、或者事件模式，让 Post （以及其他任何对此修改感兴趣的实体）连带去修改 authorAvatar （不过，如果 avatar 是实时图片的话，那么不如把 Avatar 也独立成单独实体，Post 、User 都只存不可变的 avatarId ，前端显示/数据导出的时候，再根据 avatarId 去实时获取最新图片）；

@yidinghe #55 你可以再深入一点，什么 Mybatis ，什么 Service ，什么 Controller 都是多余的，再继续一点什么前端框架也是多余的—— 原生 javascript + SQL 就够了。

@Nosub #45 这本书是付费书籍，你这又连完整原文截图都没有，你这是在自认「断章取义」，还是在自认「没看原文而是看了某人的断章取义」。

这个图应该是真的，但是它需要结合完整原文才能知道说得是什么。这里比较的很可能是，「直接用 Hibernate 的 API 」、「用 JDK 的 JPA 」 、用「 Spring Data JPA 」 ，这三种，使用 Hibernate 的途径的性能。 三个都是 Hibernate ，只不过使用方式不同。

@Nosub #41 上原文链接

@Nosub #40 JPA 是标准，Hibernate 是一种实现 ，Spirng Data JPA 跟 Hibernate 就是 Spring Boot 跟 Spring 的关系。你这来源是瞎比较，你不能下。

另请注意，数学上没有「-0 」。「-0 」是特殊领域才有的，比如计算机科学的浮点数。但气象领域，是否有 「-0 」，未明确。

负数四舍五入，要先对绝对值做，再补回符号。所以 -0 跟 0 是不一样的，一个是 (-0.5,0)，一个是[0,0,5)。

看起来很对吧，实际不对。不管是四舍五入、五舍六入，还是四舍六入，都是往找最接近的整数。四舍五入，如果严格按照四下五上的规则的话，[-0.5,0.5) 都要修到 0 。若正数四下五上，负数反过来，则(-0.5,0.5) 都要修到 0 。「负数四舍五入，要先对绝对值做，再补回符号」是个有遗漏的算法。

数据模型太烂，上谁都管不了。换成 SQL 也是复杂 SQL ，可能更慢。

1 ，数据库弄个视图，然后单独给这个试图搞个纯查询的实体吧。2 ，如果 1 不可行，跑路。

这么多关联，你这是个屁的简单查询。