相对于玉树临风的功能界面，导入，显得猥琐又懒散。但对于Web系统而言，导入，有时恰是当时境况下的更优解。

一、一个漫不经心的案例

业务场景：物流供应商制定收费规则（如下图），订单发货之后，自动进行物流费用核算。

从上图可见，规则信息项包括：渠道名称、国家、是否计材积重、材积重系数、重量区间、更低起重、运算公式。

并且：

一个渠道，可以对多个国家 。

一个渠道+国家，可以有多个重量区间。

一个渠道+国家，只能有一个更低起重，只能一个是否计材积重、以及材积重系数。

一个渠道+国家+重量区间，只能有一个计算公式。

一个渠道+国家+重量区间+起止时间，是唯一的。

……

了解了以上，基本可以设置一个创建规则的结构：

这个原型的特点之一是丑，第二个特点是存在一定量的前端交互。

但这时，出现一个客观问题——前端开发人员不够。

为了项目进度，之一版，决定采用导入的方式。

为啥呢？因为导入把页面操作都省了。

二、导入方式

在关系型数据库中（参考文章：《后端产品经理笔记之查询数据库》），数据表结构和Excel表结构相似。

所以这样的场景下，导入功能无异是短直快。

导入一般是从最小粒度开始的。一个渠道+国家+重量区间+起止时间，是最小的数据粒度。

但是看上图的表格导入，要考虑挺多问题。比如，我们知道，渠道+国家+起止时间相同的行，可以拟定为一组规则。

所谓一组，就是只有重量区间不同。那么这组拟定规则中，各行的重量区间不能有交叉：

与已经存在的同组规则的重量区间不能交叉；

起止时间不能交叉。

与已经存在的同组规则的起止时间不能交叉；

各行的更低起重要一致；

各行的是否计材积重一致；

……

整理一下要考察的项，基本和下图差不多。

这样导入，看着没毛病，实现起来事倍功半。

首先，Excel不便于做复杂校验。

尽量做轻量校验，把数据带入系统之后，在页面承担更多工作。

其次，尽量提升数据最小粒度的颗粒度。

因为粒度一旦细致，就会倍增式地出现交叉校验。

再次，尽量在摘出具有共性的参数，导入之后再统一页面处理。

基于以上现状和方向，再次回归业务进一步掉研。如下：

业务会定期给卖家提供更新的报价方案。比如对1月份发货的订单定下了价格，结果2月出现疫情，需要涨价，于是2月修订价格，应用于2月发货的订单。而我们所说的起止时间，不是规则生效的时间，而是适用于的订单的发货的时间。

以上可以看出来，其实每一次修订，都可看做一次更新迭代。每次迭代，都可以将所有变化和未变化的都导入一遍。于是就可以将起止时间独立出来，放在最外层。也就是导入的这一批适用的订单的发货时间是一致的。

再看‘是否计材积重’。

它表达的是，一些货物是否按体积折算出重量。比如一车棉花，按实际重收费就亏了。因此，这个判断的场景一般是发货的时候，由渠道定的。

所以可以统一在导入之后，与渠道做关联。也就把这项，从导入的规则明细中剔除出来。

三、做了这个导入功能

于是导入的模板就简化为这样：

正常做：

（1）导入框：

（2）校验

之一：校验导入的文件是否正确

表文件A-I是否对的上，对不上视为模板错误。直接报告文件错误，不再进入详情校验。

第二，校验内容

必填项不能为空

重量起点（g)<重量止点（g)

单元格内容需被系统识别或格式正确。

先判断不需要查表的项，再判断国家、物流渠道名称这些需要查表的项。

以A+B+C+D列判重，若存在重复的行，则对第二及其后的重复行报错.

A+B列相同的行之间，重量区间不能交叉。