相對於玉樹臨風的功能界面，導入，顯得猥瑣又懶散。但對於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協議
閱讀更多 人人都是產品經理 的文章
