循環類業務處理的「增、刪、改、查」
在處理很多業務時,有時會碰到“循環”這種特殊業務處理。例如:一個循環任務,IOS上的日歷循環計劃,工作日鬧鐘等等。本文從四個方面對循環業務展開介紹,希望對你有用。
這里就來剖析下,『循環』事務的相關業務邏輯處理方案。
本文闡述的『循環 』等同于『重復』。
一、循環實際需求
部分業務在實際使用時,想要實現定期重復的場景。
例如,用戶制定了一個每周二的提醒事項,或者是想建一個每周六健身的計劃清單,每隔兩月的1號繳納電費等費用。
這些需求都是『場景固定,時間循環往復』。
二、循環是什么
百科對其的定義是:事物周而復始地運動或變化。
具體上要結合業務點,例如循環計劃、重復提醒。其目的就是為了讓一個周期性的事務,能夠在僅做一次的情況下,在定好規則后,可以按周期出現。
三、循環規則
一個完整循環的周期=開始點+周期+結束。
開始點通常是某一個具體的日期。
常見的循環周期的方式主要包括:日、周、月、年,有的產品還出現了『艾賓浩斯』周期。
疊加了結束的循環周期,也就限定了此循環周期的時間長度。
不同的周期,所產生的具體規則細節不同。
例如:以『周』為周期的話,需要指定是周幾,具體可見下表。
X是循環開始點;Y標識所選次數;Z為截止日期。
清楚了循環的本質,接著就是要結合業務,處理業務的循環數據。
四、處理循環的數據
任何信息化事務的主要操作類型無非是『增、刪、改、查』四類。
1. 『增』:雙向處理
循環數據應該少占用資源空間,所以用時間換空間。每次循環事務的展示,都是動態組織的結果。若是用空間換時間可能帶來影響:空間消耗大;實際查詢效率也不高。
可以想象一下,若是每次設置一個循環,就根據循環規則創建一條數據,假若設置了個每天循環的計劃,光一個月的話都可能多達30條。這還僅是此業務的一條循環方案,要是多條呢?所以當業務具備『循環』時,業務的數據應該還是獨自保留的,僅是和循環子表建立關聯。
在新增數據時,就進行雙向處理:在循環表上記錄著循環的規則內容,而業務表則記錄業務數據主體。
2. 『查』:虛實結合
由于循環業務的數據是分開處理的,采用的是【時間換空間】的方式。所以在展示循環業務的時候,查詢的原則是:程序化組織,邏輯上判定,展示頁優化。
程序化組織:利用程序去向兩個表讀取數據,然后虛擬化出來相關的循環點。虛擬化是指根據循環規則判斷某日是否該有數據展示,若有,則根據業務表組織出一條虛擬數據。
例如:在1月1號制定了每天循環的事務,在2號這天查看時,也能看到此條事務數據,但實際上這條數據是通過程序拼裝出來的。
邏輯上判定:除了依靠程序拼裝點,還需邏輯檢驗比對,虛擬化的點是否有實例化過。(實例化見下文)
展示頁優化:簡單來說,就是用戶在客戶端查看時,是看不出和那些真實的業務數據的差別,看起來以及使用起來都感覺在操作實際存在的數據。
3. 『改』:實例和重塑更新
對于循環類的事務,更新的方式主要是兩類:僅更新當前,更新當前及后續。
僅更新當前:在循環體中的某一時間點,僅需要更新當前的情況。例如:用戶制定了一個每周二循環的事務清單,在第3次執行時,當天事務繁多,此清單想刪掉其中一條事務,但是后面的暫時不想更改,那就需要更新當前。
因為有些數據點是虛擬的,所以在進行更新當前時,就需要將其進行實例化,也就是新增一條,時間歸屬于當前時間點的業務數據。這也就是上文提到的邏輯上判定,在實際展示這一時間點的數據時,僅展示這一實例化的點即可。
我們可以把循環事務想象為一個點,通過循環規則,它演變為一段線段。在循環中途對循環業務進行的操作,都是對線段的操作。
更新當前及后續:從當前點開始,后面的循環內容發生了改變。這種就需要對于循環做新增,正所謂“一刀兩段”。新產生的循環就是重塑的循環。
4. 『刪』:“反常態”操作
正常的業務在進行刪除時,不是進行數據的移除,就是進行數據的假刪處理,數據不會出現因為【刪除】反而增加的情況,但是對于『循環』的業務可能就要區別對待了。
循環事務的刪除和它的更改一樣,也是具備兩項操作:僅刪除當前,刪除當前及后續。
刪除當前及后續:這個很直白,就是從某一處開始,直接截斷“扔掉”。
但是,【僅刪除當前】可就不好操作了??赡苡腥藭氲絼h除當前,直接在線段上“一刀兩段”把那個特殊點扔掉即可。我們假設這種方式叫截斷,看下截斷方式帶來的實際業務變化。
看樣子,采用截斷的方式,再進行更新操作也不會有啥影響。那假如把一段循環,在中途刪掉兩個點。例如:從1月1日到1月10日每天循環的計劃,3日和5日因為休息,不必執行了。
當刪掉了1月3日和1月5日的事務后,然后把1月4號也刪掉,再回到1月2號想調整下循環事務內容時,會發現6號到10號的循環事務內容不跟隨變化了。這也違背了上述『查』的展示頁優化。
而如果采用【補點】的方式,也就是刪除單點時,加一個覆蓋點,用于遮蓋。
上述的問題也就不存在了,但是這也造成了一個問題,明明是【刪除】操作,結果數據庫里的數據反而增多了,資源空間占用更多了。
這時就可以用到遞歸優化,在處理具體循環事務時,判定是否為唯一點,若是直接進行數據清除。對于有子集的則遞歸化處理,以來減少資源空間浪費。
五、總結
循環類事務,難點在于對于數據的處理上。理清楚具體業務的實際場景,以來定奪具體采用的處理方式。
上述是一個通式,部分也是個例。若是想完美解決,就要理清線段和點的關系,這里不再贅述。
本文由 @29號同學 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自 Unsplash,基于 CC0 協議
作者你好,有兩個地方沒有看懂,能解釋下嗎?
1.在刪除那一節,僅刪除當前的邏輯里,為何中途刪掉兩個點,更新循環及后續時,3部分就更新不到了
2.事務優化邏輯不夠清晰,部分無法理解,能否解釋下流程圖里幾個字段的意思
1.在一段循環內刪除某點時,是相當于切割,1段刪除1個點后,相當于拆成了【1】【2】兩段,其中【1】還是原本的編號循環段僅是變短了,【2】再刪除一個點就由【2】變成了【2】【3】,【2】從屬于【1】,【3】從屬于【2】,例如有個Root屬性用來記錄他們原本的父級是哪個,他們從屬于【1】,這樣再更新父級節點時,才能更新到由于切割產生的子集。
2.流程圖那部分字段可以忽略,是循環體的實體屬性,具體的可以按照公司業務來設定
讓我想起了釘釘的日志提醒功能,在假期和請假時也會提醒今日未提交日志,真是太坑了
可能因為釘釘系統的假期和請假,是做在其他系統表中,然后不好跨業務讀取,然后就沒有剔除。
當然如果把考勤類加入考慮的話,整體邏輯運算量可能加大,這可能也是一方面原因
原來如此,謝謝大佬的分享,這篇文章是我在這個平臺看到的少數硬核產品文章之一,望今后可以持續更新為盼
哈哈哈,謝謝支持,不過還不是大佬,『硬核』這個詞不錯
我還是挺喜歡技術型或者運營型的,那些轉型或者小廠的產品,沒看清問題結構就上來夸夸其談,或者各種自以為是不客觀的分析結論,一點核心競爭力都沒有,頂多只是個文員。
那么好的文章,沒人看?這屆pm 真該重置一下了,反而是一群人研究擺攤
可能切入點較小,不涉及此類業務的pm看起來就會云里霧里。更奇怪的是 這篇文章居然被定位到了【業界動態】搞不懂人人都是產品經理判定邏輯
你口氣是真的大,一棒子一敲一堆人,任何行業和職位都存在良莠不齊的情況。
然后呢,你想說我指的就是你嗎
了
一副高高在上 自以為是的樣子,你是什么牛馬?