循环类业务处理的「增、删、改、查」

13 评论 15255 浏览 53 收藏 10 分钟

在处理很多业务时,有时会碰到“循环”这种特殊业务处理。例如:一个循环任务,IOS上的日历循环计划,工作日闹钟等等。本文从四个方面对循环业务展开介绍,希望对你有用。

这里就来剖析下,『循环』事务的相关业务逻辑处理方案。

本文阐述的『循环 』等同于『重复』。

一、循环实际需求

部分业务在实际使用时,想要实现定期重复的场景。

例如,用户制定了一个每周二的提醒事项,或者是想建一个每周六健身的计划清单,每隔两月的1号缴纳电费等费用。

这些需求都是『场景固定,时间循环往复』。

二、循环是什么

百科对其的定义是:事物周而复始地运动或变化。

具体上要结合业务点,例如循环计划、重复提醒。其目的就是为了让一个周期性的事务,能够在仅做一次的情况下,在定好规则后,可以按周期出现。

三、循环规则

一个完整循环的周期=开始点+周期+结束。

开始点通常是某一个具体的日期。

常见的循环周期的方式主要包括:日、周、月、年,有的产品还出现了『艾宾浩斯』周期。

叠加了结束的循环周期,也就限定了此循环周期的时间长度。

不同的周期,所产生的具体规则细节不同。

例如:以『周』为周期的话,需要指定是周几,具体可见下表。

X是循环开始点;Y标识所选次数;Z为截止日期。

清楚了循环的本质,接着就是要结合业务,处理业务的循环数据。

四、处理循环的数据

任何信息化事务的主要操作类型无非是『增、删、改、查』四类。

1. 『增』:双向处理

循环数据应该少占用资源空间,所以用时间换空间。每次循环事务的展示,都是动态组织的结果。若是用空间换时间可能带来影响:空间消耗大;实际查询效率也不高。

可以想象一下,若是每次设置一个循环,就根据循环规则创建一条数据,假若设置了个每天循环的计划,光一个月的话都可能多达30条。这还仅是此业务的一条循环方案,要是多条呢?所以当业务具备『循环』时,业务的数据应该还是独自保留的,仅是和循环子表建立关联。

在新增数据时,就进行双向处理:在循环表上记录着循环的规则内容,而业务表则记录业务数据主体。

2. 『查』:虚实结合

由于循环业务的数据是分开处理的,采用的是【时间换空间】的方式。所以在展示循环业务的时候,查询的原则是:程序化组织,逻辑上判定,展示页优化。

程序化组织:利用程序去向两个表读取数据,然后虚拟化出来相关的循环点。虚拟化是指根据循环规则判断某日是否该有数据展示,若有,则根据业务表组织出一条虚拟数据。

例如:在1月1号制定了每天循环的事务,在2号这天查看时,也能看到此条事务数据,但实际上这条数据是通过程序拼装出来的。

逻辑上判定:除了依靠程序拼装点,还需逻辑检验比对,虚拟化的点是否有实例化过。(实例化见下文)

展示页优化:简单来说,就是用户在客户端查看时,是看不出和那些真实的业务数据的差别,看起来以及使用起来都感觉在操作实际存在的数据。

3. 『改』:实例和重塑更新

对于循环类的事务,更新的方式主要是两类:仅更新当前,更新当前及后续。

仅更新当前:在循环体中的某一时间点,仅需要更新当前的情况。例如:用户制定了一个每周二循环的事务清单,在第3次执行时,当天事务繁多,此清单想删掉其中一条事务,但是后面的暂时不想更改,那就需要更新当前。

因为有些数据点是虚拟的,所以在进行更新当前时,就需要将其进行实例化,也就是新增一条,时间归属于当前时间点的业务数据。这也就是上文提到的逻辑上判定,在实际展示这一时间点的数据时,仅展示这一实例化的点即可。

我们可以把循环事务想象为一个点,通过循环规则,它演变为一段线段。在循环中途对循环业务进行的操作,都是对线段的操作。

更新当前及后续:从当前点开始,后面的循环内容发生了改变。这种就需要对于循环做新增,正所谓“一刀两段”。新产生的循环就是重塑的循环。

4. 『删』:“反常态”操作

正常的业务在进行删除时,不是进行数据的移除,就是进行数据的假删处理,数据不会出现因为【删除】反而增加的情况,但是对于『循环』的业务可能就要区别对待了。

循环事务的删除和它的更改一样,也是具备两项操作:仅删除当前,删除当前及后续。

删除当前及后续:这个很直白,就是从某一处开始,直接截断“扔掉”。

但是,【仅删除当前】可就不好操作了。可能有人会想到删除当前,直接在线段上“一刀两段”把那个特殊点扔掉即可。我们假设这种方式叫截断,看下截断方式带来的实际业务变化。

看样子,采用截断的方式,再进行更新操作也不会有啥影响。那假如把一段循环,在中途删掉两个点。例如:从1月1日到1月10日每天循环的计划,3日和5日因为休息,不必执行了。

当删掉了1月3日和1月5日的事务后,然后把1月4号也删掉,再回到1月2号想调整下循环事务内容时,会发现6号到10号的循环事务内容不跟随变化了。这也违背了上述『查』的展示页优化。

而如果采用【补点】的方式,也就是删除单点时,加一个覆盖点,用于遮盖。

上述的问题也就不存在了,但是这也造成了一个问题,明明是【删除】操作,结果数据库里的数据反而增多了,资源空间占用更多了。

这时就可以用到递归优化,在处理具体循环事务时,判定是否为唯一点,若是直接进行数据清除。对于有子集的则递归化处理,以来减少资源空间浪费。

五、总结

循环类事务,难点在于对于数据的处理上。理清楚具体业务的实际场景,以来定夺具体采用的处理方式。

上述是一个通式,部分也是个例。若是想完美解决,就要理清线段和点的关系,这里不再赘述。

 

本文由 @29号同学 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 作者你好,有两个地方没有看懂,能解释下吗?
    1.在删除那一节,仅删除当前的逻辑里,为何中途删掉两个点,更新循环及后续时,3部分就更新不到了
    2.事务优化逻辑不够清晰,部分无法理解,能否解释下流程图里几个字段的意思

    回复
    1. 1.在一段循环内删除某点时,是相当于切割,1段删除1个点后,相当于拆成了【1】【2】两段,其中【1】还是原本的编号循环段仅是变短了,【2】再删除一个点就由【2】变成了【2】【3】,【2】从属于【1】,【3】从属于【2】,例如有个Root属性用来记录他们原本的父级是哪个,他们从属于【1】,这样再更新父级节点时,才能更新到由于切割产生的子集。
      2.流程图那部分字段可以忽略,是循环体的实体属性,具体的可以按照公司业务来设定

      来自江苏 回复
  2. 让我想起了钉钉的日志提醒功能,在假期和请假时也会提醒今日未提交日志,真是太坑了

    来自广东 回复
    1. 可能因为钉钉系统的假期和请假,是做在其他系统表中,然后不好跨业务读取,然后就没有剔除。
      当然如果把考勤类加入考虑的话,整体逻辑运算量可能加大,这可能也是一方面原因

      来自江苏 回复
    2. 原来如此,谢谢大佬的分享,这篇文章是我在这个平台看到的少数硬核产品文章之一,望今后可以持续更新为盼

      来自广东 回复
    3. 哈哈哈,谢谢支持,不过还不是大佬,『硬核』这个词不错

      来自江苏 回复
  3. 我还是挺喜欢技术型或者运营型的,那些转型或者小厂的产品,没看清问题结构就上来夸夸其谈,或者各种自以为是不客观的分析结论,一点核心竞争力都没有,顶多只是个文员。

    回复
  4. 那么好的文章,没人看?这届pm 真该重置一下了,反而是一群人研究摆摊

    回复
    1. 可能切入点较小,不涉及此类业务的pm看起来就会云里雾里。更奇怪的是 这篇文章居然被定位到了【业界动态】搞不懂人人都是产品经理判定逻辑

      来自江苏 回复
    2. 你口气是真的大,一棒子一敲一堆人,任何行业和职位都存在良莠不齐的情况。

      来自广东 回复
    3. 然后呢,你想说我指的就是你吗

      回复
    4. 回复
    5. 一副高高在上 自以为是的样子,你是什么牛马?

      来自江苏 回复