一个外包同事，插入 200 条数据，调用了四万次人员查询接口

能跑就行

不对啊,你这又不是直接查数据库,用的接口啊,只能怪你接口慢罗,谁知道你们有没有批量查询接口

@devopsdogdog hhhh 就在找你这句

我的表几百万条查询几秒钟，你们是土豆服务器？要么花钱请好程序员，要么花钱上好服务。

@chenqh

（ 1 ）需求为 A 系统的流程数据迁移到 B 系统，但是在 B 系统是只读的，A 系统已经停用不再产生数据也不再修改人员结构
（ 2 ） A 系统和 B 系统的人员的数据库主键都不是工号，但是同一个人工号在两个系统是相同的，人员同步每天半夜执行，也就是说白天上班期间人员的 ID 是不会变的，就算同步了也不会变
（ 3 ） A 系统采用查库获取数据，B 系统使用接口（访问接口需要 accessToken ）插入数据
（ 4 ）迁移的流程数据包括主表单、审批意见，每一个审批单包含 2 条主表记录和若干审批意见表中的记录（可以通过流程 ID 一次查出对应单据的所有审批意见）
（ 5 ）审批意见里的人员需要 A 系统 ID -> 工号 -> B 系统 ID 这样转换后才能插入，所以需要调人员查询接口
（ 6 ） B 系统插入新数据只需要调用一次插入接口（ json post ）

不对啊,就算没有批量,4W 次是怎么弄出来的,就算每条记录 10 个用户,查 A 系统 10 次,B 系统 10,也就 200*20=4000 次

和水平不行的人共事的确糟心；虽然 LZ 有点拉偏架，不过外包现状如此，不排除外包里有能人，但是外包的低门槛也导致里面菜的比例就是更多；

@cassyfar 以后国产化就这服务器了，除非华为点出什么天顶星科技能追上至强或者 epyc 的性能

200 条数据怎么插也不会查询数据库两万次吧

JPA 的话感觉是没写 EntityGraph

馬鈴薯伺服器.

2000 年，一位名為佛瑞德·懷特的男子創造了一台用 5 個馬鈴薯為動力的 Web 伺服器，這伺服器每秒鐘僅可以處理 0.2 個頁面請求，也就是說大概 5 秒鐘才能處理一個完整的用戶請求。

op 公司现在也不招自社员工，统一用外包了吗。

设计的问题不能光给一个人背，方案是谁出的，有没有 review ，如果都然后一个外包写那么锅是研发组长的

@murmur 评价是外包啥都要，只要甲方能过就行， 市场都要有经验的，没经验的大多干外包，一部分转行，一部分自己找到非外包工作（但是有可能是项目外包）

@broken123 #56 😭我当年实习的时候, 就是 3 层 for 循环...

@nothingistrue 這種地方有個屁的代碼評審 代碼不崩就當通過了

涉及到多这个表的查询，找 DBA 给 sql 或建好视图查询， 开发不管数据库这类的东西，哪是数据部门的事。

哈哈，我要是干上外包了，我也这么写，反正都干外包了，能用就行。

人和代码有一个能跑就行(●'◡'●)

項目用低代碼就別想著性能好，外包都是拼命的壓榨，哪有時間給你優化，能實現功能就不錯了。而且低代碼的底層邏輯都不知道，一般公司的低代碼平台還是不停迭代的，最開始可能只能用笨方法實現功能，後期才有解決方案。