web系统中，导入功能的设计要点

　　相对于玉树临风的功能界面，导入，显得猥琐又懒散。但对于Web系统而言，导入，有时恰是当时境况下的最优解。
　　一、一个漫不经心的案例
　　业务场景：物流供应商制定收费规则（如下图），订单发货之后，自动进行物流费用核算。
　　从上图可见，规则信息项包括：渠道名称、国家、是否计材积重、材积重系数、重量区间、最低起重、运算公式。
　　并且：
　　一个渠道，可以对多个国家。
　　一个渠道国家，可以有多个重量区间。
　　一个渠道国家，只能有一个最低起重，只能一个是否计材积重、以及材积重系数。
　　一个渠道国家重量区间，只能有一个计算公式。
　　一个渠道国家重量区间起止时间，是唯一的。
　　了解了以上，基本可以设置一个创建规则的结构：
　　这个原型的特点之一是丑，第二个特点是存在一定量的前端交互。
　　但这时，出现一个客观问题前端开发人员不够。
　　为了项目进度，第一版，决定采用导入的方式。
　　为啥呢？因为导入把页面操作都省了。
　　二、导入方式
　　在关系型数据库中（参考文章：《后端产品经理笔记之查询数据库》），数据表结构和Excel表结构相似。
　　所以这样的场景下，导入功能无异是短直快。
　　导入一般是从最小粒度开始的。一个渠道国家重量区间起止时间，是最小的数据粒度。
　　但是看上图的表格导入，要考虑挺多问题。比如，我们知道，渠道国家起止时间相同的行，可以拟定为一组规则。
　　所谓一组，就是只有重量区间不同。那么这组拟定规则中，各行的重量区间不能有交叉：
　　与已经存在的同组规则的重量区间不能交叉；
　　起止时间不能交叉。
　　与已经存在的同组规则的起止时间不能交叉；
　　各行的最低起重要一致；
　　各行的是否计材积重一致；
　　整理一下要考察的项，基本和下图差不多。
　　这样导入，看着没毛病，实现起来事倍功半。
　　首先，Excel不便于做复杂校验。
　　尽量做轻量校验，把数据带入系统之后，在页面承担更多工作。
　　其次，尽量提升数据最小粒度的颗粒度。
　　因为粒度一旦细致，就会倍增式地出现交叉校验。
　　再次，尽量在摘出具有共性的参数，导入之后再统一页面处理。
　　基于以上现状和方向，再次回归业务进一步掉研。如下：
　　业务会定期给卖家提供更新的报价方案。比如对1月份发货的订单定下了价格，结果2月出现疫情，需要涨价，于是2月修订价格，应用于2月发货的订单。而我们所说的起止时间，不是规则生效的时间，而是适用于的订单的发货的时间。
　　以上可以看出来，其实每一次修订，都可看做一次更新迭代。每次迭代，都可以将所有变化和未变化的都导入一遍。于是就可以将起止时间独立出来，放在最外层。也就是导入的这一批适用的订单的发货时间是一致的。
　　再看‘是否计材积重’。
　　它表达的是，一些货物是否按体积折算出重量。比如一车棉花，按实际重收费就亏了。因此，这个判断的场景一般是发货的时候，由渠道定的。
　　所以可以统一在导入之后，与渠道做关联。也就把这项，从导入的规则明细中剔除出来。
　　三、做了这个导入功能
　　于是导入的模板就简化为这样：
　　正常做：
　　（1）导入框：
　　（2）校验
　　第一：校验导入的文件是否正确
　　表文件AI是否对的上，对不上视为模板错误。直接报告文件错误，不再进入详情校验。
　　第二，校验内容
　　必填项不能为空
　　重量起点（g）重量止点（g）
　　单元格内容需被系统识别或格式正确。
　　先判断不需要查表的项，再判断国家、物流渠道名称这些需要查表的项。
　　以ABCD列判重，若存在重复的行，则对第二及其后的重复行报错。
　　AB列相同的行之间，重量区间不能交叉。
　　交叉的规则：假设重量区间ab、ef，若出现b、f、b、f任一种情况，则视为这两个区间交叉，则对第二及其后的重复行报错。
　　这里为啥不校验系统已存在的数据呢？
　　因为我们用起止时间，将这种本次导入与历史数据的重复规避掉了。具体就是：
　　全部校验通过，导入这一批，生成一个批次号，这个批次号需要编辑一个起止时间，这个起止时间不能与其他批次号的起止时间交叉。
　　这时候还余下一个参数：是否计材积重。在编辑时间的时候进行编辑即可。如下图：
　　总结这个案例，物流费用规则的页面有两层：
　　（1）列表页：版本号维度。每成功导入一次，则生成一条对应的版本号数据。
　　每个版本号对应一批规则，对应同一个适用时间，因此通过版本号标定这一批规则，并将适用时间与版本号进行关联，而不与具体的规则明细关联，简单清晰。贴近业务场景。
　　（2）明细页：显示某一版本号下的全部规则明细。也就是导入的每一行规则。
　　四、姗姗来迟的小结
　　（1）导入的本质：
　　是将Excel的指定列，赋予数据库的某个字段，比如A列对应字段‘渠道名称’。
　　（2）导入时候的校验项很多，一条数据不止命中一个错误。
　　一般而言，按规则的顺序，每一行只报一个错误原因。
　　（3）因为可能需要反复校验多个校验项，所以依次进行，从简到难。比如：
　　优先是必填项不能为空，单元格内容格式正确。
　　然后才是核对数据是否存在于基础数据库中；
　　最后检测本次导入与已存在数的冲突性校验，比如重复。
　　（4）每校验一项内容，都将全部数据跑完。
　　比如四个校验项，100条数据。
　　先跑校验项1，将各行都检测完；都没错，则跑规则2，出错则报错。
　　下次修复后再次导入，则还是从验项一跑到验项四。
　　（5）导入的格式与性能有关
　　CSV格式的系统开心，秒传，但是用户优势不大喜欢。Excel相反。
　　（6）与历史数据的更新还是覆盖？这个情况让用户选了。
　　（7）一旦一条出错，是否全部不予导入呢？
　　一般而言，若是提交给另外的系统，那通过的基本就写入了，就没法回滚了。所以就部分正确则部分导入。
　　如果是自己系统，一般一旦一个写入错误，则全部回滚，全部检查，直至全部OK才写入。确保完整性。
　　（8）报错的方式
　　十几二十条就在弹框说明谁是错的就可以。过多数据的就Excel报错。
　　（9）Excel模板可以做什么？
　　可以加表头标注，加注释说明，加第二分页。但是要开发知道。说明哪些区域是导入区。
　　（10）导入是猥琐的。但是也有主动使用导入的场景，比如：
　　从1688导出了订单的采购信息，包括物流单号等。这时候如果要把物流单号加到自己系统中去，一个个加入肯定费劲，直接导入就很快了。
　　另外其实案例的这个数据量上千，导入也是比较合适的。所以导入的功能是猥琐了点，但是有时候可以大用。