@orange323787 前端时间带公司的实习生，HR 进来时给人家说试用 3 月 800 ，3 个月如果转正 3000 。结果转正了只给 1000 ，哐哐跑了。我算了算，一个月伙食和交通开销也不止这个数，这个行情真的时逼人走。

长沙还有没有别的开放的岗位

@Battle 这几年入职和离职，在现在不行的情况下，我认为大部分找工作的对职位的预期和实际都会有落差，吃过了细粮现在只能吃糟糠，心也不稳定，其实最好的状态就是入职到一个稳定且融洽的公司，待遇能慢慢增长最好。但是这个情况算是难了。

@ShrinkLynn HR 被裁，应该没啥扯的，算是分工作善终吧。

@qwertty01 比如我们公司的用户系统，就单独用了一个库，库下面更加用户功能的情况拆开来了几个模式。其他的各个独立业务线，各自用库然后拆分模式。
这个划分就是拆分上延展到数据库的结果，各个业务不影响干扰，最后上层搭配合理的跨系统调用实现。
对于 pg 本身而言，这玩意就是数据管理的分层思维体现，按实际业务划分即可。不过系统小就大可不必了，直接单库一把梭都没事，还省得跨库查询不方便。

我们公司用的 pg ，分库偏向于分系统，而分模式偏向于分模块，非公共应用和必要情况下不要 public

好帖要赞，找工作要去了解 hr 才更有机会

在掌机上搓塞尔达缩小帽

@lupus721 一看国产还付费，我们这就有人跳出来龇牙咧嘴了

考虑广度的可发展机会更多，东边不亮西边亮吧，但如果都是皮毛也就不过尔尔了。考虑深度的话，如果走对了路，可以走得更远更好，但反之可能进死胡同。
这个问题有点像读大学报学校报专业，如果知道自己想干嘛，那就有限选深度，如果不知道自己想干嘛，那就有限广度。至于后面的发展，看个人际遇了。

个把人用就弄个 excel 模板方便，我这边三四个人就是 excel 管理，整个公司用 OA ，以前十来个人的时候用的禅道

事实证明，1.rewriteBatchedStatements 参数作为 url 的传参并未生效，pg 的执行方式还是单条导致慢，2.用 2 楼的方式使用单次 update 效率是可以接受的，不过具体的更新条目量得根据实际情况调整； 3. update case when 的写法不推荐，特别是多参数大量更新时可能出现超长的问题。

@ZhanXinjia 上面就是用的原始 jdbc ；如果用这个 update 拼接的写法，单个 SQL 很长，我有点担心 sql 能否执行下去；我先得把单线程的效率干上去，才能去考虑多线程。

@xiwh connection.setAutoCommit(false);然后再 commit ，这是个整体提交的事务，但是我看到最终连接后，执行再数据库的连接慢，至于数据库里面怎么执行慢的不确定了

@akira 加密很快，问题在于数据库的 update 操作