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

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

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

一、循环实际需求

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

例如,用户制定了一个每周二的提醒事项,或者是想建一个每周六健身的计划清单,每隔两月的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号同学

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部