SoviaPhilo

@seth19960929 如果 mock 了数据库，建议是把这部分直接和业务逻辑剥离， 还更靠谱些。

巧了， 我手上有个项目有类似的需求， 而且也用上面的方式做了统一处理

然后一年以后我就不再用这玩意儿了。
一个问题是管理员需要操作全量数据， 意味着要维护 selectIgnore
另一个问题是出现了相似的相对含义字段，类比一下就是业务增加了第二个 会计期间，而且要基于这个做逻辑
第三个问题是业务性条件，非显式地填充事实上增加了潜在成本

考虑到 PO 的视野根本看不了这么远， 直接用你的方案 1 算了

所有人都知道这个东西不靠谱， 但是老板就是相信这个


顺便一提， 我现在所在的团队推敏捷， 实际落地的时候一个项目组同时负责两个 sprint 的开发。
再加上潜在的线上问题运维支持的时间，以及随时都会有的 BI 协助要求
就这敏捷总监还说大家估时要准确，不要注水。


不注水就死定了

成年人要明白一个道理， 就是谁承担最大的后果， 就应该承担最大的责任。

你们公司有正经组织工程师培训什么叫优雅吗？
你们公司有愿意为了更优雅的代码付出更多时间成本吗？

没有？又不是你的项目， 老板都不急你急什么

RDB 是全量备份，全量备份意味着要比 AOF 更重， 也就意味着你不可能每秒一次 RDB
如果真的要用 Redis 做持久化， 视数据的重要性，可能是要两个都开的