@RuLaiFo #32 所以说没有卖不掉的房子只有卖不掉的价格，如果真的是好生意急用钱，降十万就秒出了。

还有一些细节也挺让人迷惑的：
1.成都有收彩礼的风俗？本地数十年土著表示认识的家庭没有见过？
2.房子加名字不必须在购房时，购房后几十元就能把对方名字加上。
3.“去年下半年成都房子就很难卖了，所以一直没卖掉”vs“因为卖了以后就很难买了，房价会越来越贵”？到底是难卖还是难买？

说伏地魔的是不是只看标题？
通篇看下来，OP 只在最后一段说到弟弟，而且实锤的就一点“逢年过节，生日这些都会给几百块红包给他们和弟弟”，其他都是 OP 估计以后会怎么怎么样。
逢年过节给几百红包就是伏地魔了？ V2 各位的 MIN(经济条件,胸怀)≈500 ￥？

OP 前面写了很多经济细节，说实话没有任何一点跟弟弟有关系。完全站在第三方立场来看，男女平分，最多姐弟婿三人平分是合理的吧，而 OP 居然提出来弟 100%承担（她弟弟以后尽主要赡养义务）我也是妹想到。

以上是理中客分析。

要问建议，一个字分。双方三观有不可弥合的矛盾。

@carrie96 #50 本质是待办，我只是在想是不是能借用通知来实现。

@carrie96 #48 不是已读就 OK ，需要的是已经处理了才 OK 。

@buliugu #45 差不多，我也是通过用户所属的角色组来查询的，但是每种事务有独特的查询规则。签收这个操作没看出来能改善哪方面。。。

@wolfie #43 谢谢你的热心回复。不过现在其实没有已经建好的待办表。实际的表格例如 [项目表] ：项目内容字段、商务评审人、财务评审人、风控评审人、技术评审人 1 、技术评审人 2 、技术评审人 3 、项目进度、项目毛利。
要求是项目如果毛利低于 30%需要加入风控评审和技术评审人 3 ；如果项目涉及到定制开发，需要技术评审人 2 和技术评审人三；商务评审人只评审他自己的项目以及他下属的项目。

这样的要求涉及到其他类似的几十个单据表格。

OP 是不是有种自己是社会主义接班人的错觉？

@kop1989smurf #40 这个接近于我说的第二个方案。处理完待办后怎么-1 呢？

@wolfie #37 因为数据是围绕业务单据组织的，比如一个项目审核，需要 10 个角色参加，查询的时候是先筛选出符合条件的项目，再根据项目负责人和参与人找到需要推送的评审对象。这个过程不是查一张表那么简单和快速。

@kop1989smurf #31 某些部分是类似抢单的，不过抢单我理解是单一任务类型，但是推送大量用户；我这个是反过来用户不多，但是任务类型很多，所以过滤并更新任务表是个核心问题。

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

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

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

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

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

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

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

@Saxton #15 也算产品吧。