V2EX › shyrock 的所有回复 › 第 95 页 / 共 269 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 91 92 93 94 95 96 97 98 99 100 ... 269

❮

❯

2022-06-16 14:08:27 +08:00

回复了 shyrock 创建的主题 › 程序员 › 一种介于待办和通知的需求有没有好的思路？

@murmur #30 一分钟是最坏的情况，比如管理员登陆，有上百个待办列表要刷新。重点在于每个待办并不是提前筛选到待办表的，而是要根据业务逻辑一个一个查出来。

如果有待办表，那么问题就转化为怎么来更新这个待办表。

2022-06-16 11:50:29 +08:00

回复了 shyrock 创建的主题 › 程序员 › 一种介于待办和通知的需求有没有好的思路？

@libook #26 如果是历史债务，越换越少还好。我认为这个是架构没有匹配待办这个业务，意味着每一个新增的流程都会需要考虑怎么加入待办，以及怎么优化待办性能。这种情况，我认为优化单个待办的性能就是个无底洞一样的任务了。

2022-06-16 11:48:28 +08:00

回复了 shyrock 创建的主题 › 程序员 › 一种介于待办和通知的需求有没有好的思路？

@Saxton #25 每一种业务有不同的表，对吧？现在要把所有业务的待办列到一个待办列表里，中间必然有一个步骤是查询多种业务表，然后生成待办。可以选择在客户点开待办的时候去查，也可以先在后台查好在推送到前端。

2022-06-16 11:42:04 +08:00

回复了 shyrock 创建的主题 › 程序员 › 一种介于待办和通知的需求有没有好的思路？

@Saxton #22 归根结底待办是业务逻辑的延申，随业务逻辑的变更而变。
如果一开始业务逻辑就抽象了业务和待办的关系--比如用工作流引擎和事务来封装业务逻辑，
那么待办逻辑也可以聚焦起来。
现在在屎山里面抽丝剥茧新增待办逻辑确实很难优雅。

2022-06-16 11:37:32 +08:00

回复了 shyrock 创建的主题 › 程序员 › 一种介于待办和通知的需求有没有好的思路？

@libook #21 我感觉优化很难，因为一个用户可能有数十种待办，每种待办意味着一套独立的查询。针对每个查询可以优化，但是投入和产出不成正比。

2022-06-16 11:28:11 +08:00

回复了 eitomomobaohua 创建的主题 › 生活 › 老实人的神奇经历

我怀疑是妹子身上的味道不行，比如酒味太重。
如果有龙涎香的味道，不信硬不起来。

2022-06-16 11:26:00 +08:00

回复了 shyrock 创建的主题 › 程序员 › 一种介于待办和通知的需求有没有好的思路？

@Saxton #15 也算产品吧。

2022-06-16 11:25:23 +08:00

回复了 shyrock 创建的主题 › 程序员 › 一种介于待办和通知的需求有没有好的思路？

@Saxton #17 你说的这个方法就不是点击时主动查询了，实际上是后台查出来后更新到一个待办表，问题在于待办表什么时候插入记录？这里有两个选择：一是定时轮询，好处是可以外挂逻辑，不用侵入到业务代码。缺点是要为每个人的每种待办查询，速度是个问题 i ；
二是在业务逻辑中判断并插入到待办，缺点是侵入了业务代码，要改的地方很多很分散。。。

2022-06-16 11:19:59 +08:00

回复了 shyrock 创建的主题 › 程序员 › 一种介于待办和通知的需求有没有好的思路？

@nothingistrue #14 确实也是从消息导航到处理界面。重点还是第一个问题，每次即时查询待办太慢，所以才想是否可以用通知代替即时查询。。。

2022-06-16 11:18:19 +08:00

回复了 shyrock 创建的主题 › 程序员 › 一种介于待办和通知的需求有没有好的思路？

@nothingistrue #12 问题在于主动查询太慢了，有些岗位十多二十个待办种类，每一个都即时查询很花时间。

2022-06-16 11:10:05 +08:00

回复了 shyrock 创建的主题 › 程序员 › 一种介于待办和通知的需求有没有好的思路？

@Saxton #10 意思是看通知，待办数量是 1 ，点进去看待办数量是 0 ？（因为已经后台监控修改了待办状态）

2022-06-16 11:08:49 +08:00

回复了 eitomomobaohua 创建的主题 › 生活 › 老实人的神奇经历

喝醉的妹子，还能帮你找位置？到底谁喝醉了。。。