联通便宜就无脑联通。电信骨干网动不动就搞微软搞 Cloudflare ，烦得要死。

首先来说，你们公司的做法没问题。不过这样缴公司方面有点冤大头的感觉——基数越大公司部分缴的更多。

至于多交还是少交好，都懒得说了，总有沙雕不把社会保险当保险。就把社保的本质说一下你自行判断。

养老保险，规则其实经常变（其实光这点你就知道不靠谱了），但变来变去，他都可以归类为储蓄性保险的范畴。储蓄性值的保险，不看通胀都超值，一看通胀全是垃圾投资，投资越多亏越多。

医疗保险要分成两部分看。个人账户部分就是专项储蓄，不是保险，缴多缴少都无所谓。统筹部分不管保费是多少，保额都是固定的，严格的说是它是社会福利而不是保险，这就没必要再去考虑较多缴少。

公积金就是专项储蓄，缴多缴少都无所谓。但是，这是活期储蓄，要注意通胀。

剩下的工伤、生育、失业，占比小到可以忽略，就不说了。

卸载。弄个虚拟机，里面专门装各种国产软件。

@nuomi196500 #43 始发站买短坐满（你只要开放，春运期间绝对座票站票都满），然后中间都补长程票，中间站你还想上人？看来你是真没坐过真正繁忙的春运火车。

你假定了都是买长走短的，那么那些真正长程的人呢？不过就是说得好听，背地里就是把真正长程需要的人往死里摁。这你想要别人留口德？

@nuomi196500 #28 照你这样搞，你是想让大量买不到长程票没法做回家计划的人，和买了票上不去车的人，去砍你吗？

当预期火车全程满员的时候，A-D 和 A-B 一样锁定 B-C B-D C-D 等，所以出票只能是先放长再放短。如果你先把 A-B B-C ，那么要么你把买了 A-B 想去 D 的人在 B 站轰下去，要么买了 B-C 的人上不去车。

另一方面，不难看出你是要买短程的，并且还是中间站。那么不用管别人砍不砍你了，照你的思路你自己就上不了车。往前捣个 20 年，那时候别说买短补长，你 1 元钱买个站台票就能先上车后补票，结果就是春运期间只能买始发站的票——中间站你有票没票都上不了车。

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

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

@xmumiffy 林北这回有闲功夫，就给你说说年终奖单独计税的优惠点在哪里。https://www.v2ex.com/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 上原文链接