V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  nothingistrue  ›  全部回复第 16 页 / 共 109 页
回复总数  2174
1 ... 12  13  14  15  16  17  18  19  20  21 ... 109  
联通便宜就无脑联通。电信骨干网动不动就搞微软搞 Cloudflare ,烦得要死。
323 天前
回复了 chunXD 创建的主题 职场话题 五险一金是多交好还是少交好
首先来说,你们公司的做法没问题。不过这样缴公司方面有点冤大头的感觉——基数越大公司部分缴的更多。

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

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

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

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

剩下的工伤、生育、失业,占比小到可以忽略,就不说了。
323 天前
回复了 test9106 创建的主题 Windows QQ 游戏弹出广告怎么禁掉啊
卸载。弄个虚拟机,里面专门装各种国产软件。
@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 元钱买个站台票就能先上车后补票,结果就是春运期间只能买始发站的票——中间站你有票没票都上不了车。
324 天前
回复了 unt 创建的主题 职场话题 今天才知道年终奖一次性计税的惊天 bug
@mschultz 哥们看一下我单独发的主题,虽然现在这种算法问题很大,但你希望那种方式是不可能存在的。
324 天前
回复了 keakon 创建的主题 MacBook Pro 官翻机和资源机的真实来源是什么?
有保修跟没保修,那是天壤之别。官翻机属于新机系列,资源机属于二手系列。就算那个二手商说得话是真得,也别去傻乎乎的去买资源机。
325 天前
回复了 unt 创建的主题 职场话题 今天才知道年终奖一次性计税的惊天 bug
@xmumiffy 林北这回有闲功夫,就给你说说年终奖单独计税的优惠点在哪里。https://www.v2ex.com/t/1014190
325 天前
回复了 unt 创建的主题 职场话题 今天才知道年终奖一次性计税的惊天 bug
@xmumiffy #70 所以你是并不理解,个税改成按年后,年终奖单独计税的优惠点在哪里了?啥都不懂在这里狂按键盘。
325 天前
回复了 unt 创建的主题 职场话题 今天才知道年终奖一次性计税的惊天 bug
@xmumiffy #63 要搞「嗟,来食」吗。先来考考你,年终奖单独计算是哪里优惠。来看看你是真赵还是精赵。
不如直接把公司所有业务都仍虚拟机里面。
你怎么能理解到国外都是公有 SaaS ,难道微软给国防部的云(假如没被亚马逊搞真拿下订单的话),会是公有云上的租户,那铁定是私有云。

这个问题的核心关键不是公有跟私有,而是你到底是部署来给谁用的,给内部人用的那就私有部署,给公众用的那就从公有云上租
325 天前
回复了 unt 创建的主题 职场话题 今天才知道年终奖一次性计税的惊天 bug
@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 的关系。你这来源是瞎比较,你不能下。
1 ... 12  13  14  15  16  17  18  19  20  21 ... 109  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1164 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 33ms · UTC 18:27 · PVG 02:27 · LAX 10:27 · JFK 13:27
Developed with CodeLauncher
♥ Do have faith in what you're doing.