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

在处理很多业务时，有时会碰到“循环”这种特殊业务处理。例如：一个循环任务，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 协议