相對於玉樹臨風的功能界面,導入,顯得猥瑣又懶散。但對於Web系統而言,導入,有時恰是當時境況下的最優解。
一、一個漫不經心的案例
業務場景:物流供應商制定收費規則(如下圖),訂單發貨之後,自動進行物流費用核算。
從上圖可見,規則信息項包括:渠道名稱、國家、是否計材積重、材積重係數、重量區間、最低起重、運算公式。
並且:
- 一個渠道,可以對多個國家 。
- 一個渠道+國家,可以有多個重量區間。
- 一個渠道+國家,只能有一個最低起重,只能一個是否計材積重、以及材積重係數。
- 一個渠道+國家+重量區間,只能有一個計算公式。
- 一個渠道+國家+重量區間+起止時間,是唯一的。
- ……
瞭解了以上,基本可以設置一個創建規則的結構:
這個原型的特點之一是醜,第二個特點是存在一定量的前端交互。
但這時,出現一個客觀問題——前端開發人員不夠。
為了項目進度,第一版,決定採用導入的方式。
為啥呢?因為導入把頁面操作都省了。
二、導入方式
在關係型數據庫中(參考文章:《後端產品經理筆記之查詢數據庫》),數據表結構和Excel表結構相似。
所以這樣的場景下,導入功能無異是短直快。
導入一般是從最小粒度開始的。一個渠道+國家+重量區間+起止時間,是最小的數據粒度。
但是看上圖的表格導入,要考慮挺多問題。比如,我們知道,渠道+國家+起止時間相同的行,可以擬定為一組規則。
所謂一組,就是隻有重量區間不同。那麼這組擬定規則中,各行的重量區間不能有交叉:
- 與已經存在的同組規則的重量區間不能交叉;
- 起止時間不能交叉。
- 與已經存在的同組規則的起止時間不能交叉;
- 各行的最低起重要一致;
- 各行的是否計材積重一致;
- ……
整理一下要考察的項,基本和下圖差不多。
這樣導入,看著沒毛病,實現起來事倍功半。
首先,Excel不便於做複雜校驗。
儘量做輕量校驗,把數據帶入系統之後,在頁面承擔更多工作。
其次,儘量提升數據最小粒度的顆粒度。
因為粒度一旦細緻,就會倍增式地出現交叉校驗。
再次,儘量在摘出具有共性的參數,導入之後再統一頁面處理。
基於以上現狀和方向,再次迴歸業務進一步掉研。如下:
業務會定期給賣家提供更新的報價方案。比如對1月份發貨的訂單定下了價格,結果2月出現疫情,需要漲價,於是2月修訂價格,應用於2月發貨的訂單。而我們所說的起止時間,不是規則生效的時間,而是適用於的訂單的發貨的時間。
以上可以看出來,其實每一次修訂,都可看做一次更新迭代。每次迭代,都可以將所有變化和未變化的都導入一遍。於是就可以將起止時間獨立出來,放在最外層。也就是導入的這一批適用的訂單的發貨時間是一致的。
再看‘是否計材積重’。
它表達的是,一些貨物是否按體積折算出重量。比如一車棉花,按實際重收費就虧了。因此,這個判斷的場景一般是發貨的時候,由渠道定的。
所以可以統一在導入之後,與渠道做關聯。也就把這項,從導入的規則明細中剔除出來。
三、做了這個導入功能
於是導入的模板就簡化為這樣:
正常做:
(1)導入框:
(2)校驗
第一:校驗導入的文件是否正確
表文件A-I是否對的上,對不上視為模板錯誤。直接報告文件錯誤,不再進入詳情校驗。
第二,校驗內容
- 必填項不能為空
- 重量起點(g)
- 單元格內容需被系統識別或格式正確。
先判斷不需要查表的項,再判斷國家、物流渠道名稱這些需要查表的項。
- 以A+B+C+D列判重,若存在重複的行,則對第二及其後的重複行報錯.
- A+B列相同的行之間,重量區間不能交叉。
交叉的規則:假設重量區間a-b、e-f,若出現a< e
這裡為啥不校驗系統已存在的數據呢?
因為我們用起止時間,將這種本次導入與歷史數據的重複規避掉了。具體就是:
全部校驗通過,導入這一批,生成一個批次號,這個批次號需要編輯一個起止時間,這個起止時間不能與其他批次號的起止時間交叉。
這時候還餘下一個參數 :是否計材積重。在編輯時間的時候進行編輯即可。如下圖:
總結這個案例,物流費用規則的頁面有兩層:
(1)列表頁:版本號維度。每成功導入一次,則生成一條對應的版本號數據。
每個版本號對應一批規則,對應同一個適用時間,因此通過版本號標定這一批規則,並將適用時間與版本號進行關聯,而不與具體的規則明細關聯,簡單清晰。貼近業務場景。
(2)明細頁:顯示某一版本號下的全部規則明細。也就是導入的每一行規則。
四、姍姍來遲的小結
(1)導入的本質:
是將Excel的指定列,賦予數據庫的某個字段,比如A列對應字段‘渠道名稱’。
(2)導入時候的校驗項很多,一條數據不止命中一個錯誤。
一般而言,按規則的順序,每一行只報一個錯誤原因。
(3)因為可能需要反覆校驗多個校驗項,所以依次進行,從簡到難。比如:
- 優先是必填項不能為空,單元格內容格式正確。
- 然後才是核對數據是否存在於基礎數據庫中;
- 最後檢測本次導入與已存在數的衝突性校驗,比如重複。
(4)每校驗一項內容,都將全部數據跑完。
比如四個校驗項,100條數據。
先跑校驗項1,將各行都檢測完;都沒錯,則跑規則2,出錯則報錯。
下次修復後再次導入,則還是從驗項一跑到驗項四。
(5)導入的格式與性能有關
CSV格式的系統開心,秒傳,但是用戶優勢不大喜歡。Excel相反。
(6)與歷史數據的更新還是覆蓋?這個情況讓用戶選了。
(7)一旦一條出錯,是否全部不予導入呢?
一般而言,若是提交給另外的系統,那通過的基本就寫入了,就沒法回滾了。所以就部分正確則部分導入。
如果是自己系統,一般一旦一個寫入錯誤,則全部回滾,全部檢查,直至全部OK才寫入。確保完整性。
(8)報錯的方式
十幾二十條就在彈框說明誰是錯的就可以。過多數據的就Excel報錯。
(9)Excel 模板可以做什麼?
可以加表頭標註,加註釋說明,加第二分頁。但是要開發知道。說明哪些區域是導入區。
(10)導入是猥瑣的。但是也有主動使用導入的場景,比如:
從1688導出了訂單的採購信息,包括物流單號等。這時候如果要把物流單號加到自己系統中去,一個個加入肯定費勁,直接導入就很快了。
另外其實案例的這個數據量上千,導入也是比較合適的。所以導入的功能是猥瑣了點,但是有時候可以大用。
#專欄作家#
唧唧歪歪PM,公眾號:唧唧歪歪PM(ID:jjyypm),人人都是產品經理專欄作家。書籍《後端產品經理寶典》作者,藥學碩士轉行互聯網產品多年;熟悉跨境電商業務,醫藥領域;擅長大型後臺體系,社交App。
題圖來自Unsplash,基於CC0協議
閱讀更多 人人都是產品經理 的文章