第一篇里我们简单的介绍了，接收EDI报文的通用方法，那么怎么才能知道接收的数据的正确性，和可用性哪？这就需要我们来仔细的验证数据的有效性，并导入我们自己的系统中了。
上一篇我们讲到，要把数据接收到一些“数据库表”中，那么这些表，应该怎么设计哪？是不是就是系统中正在使用的表哪？
据我的实践总结出：应该建立一些中间表存储这些数据。这主要是因为
1.你不知道要接收的数据的长度
2.中间表与系统无关，不影响现有系统的运行
3.便于扩展
最简单的设计是：
CREATE TABLE(
COL1 VARCHAR2(255),
COL1 VARCHAR2(255),
COL1 VARCHAR2(255),
COL1 VARCHAR2(255),
COL1 VARCHAR2(255),
......
)
这可能会浪费空间，但是，我们不得不承认，这的确是什么数据都可以接进来的表。一种灵活的设计是，我可以动态的增加删除，修改这些中间表的结构。但是，我们最好是把字段的类型都设置为字符类型，因为这样，我们接收的时候几乎是可以接收所有数据的，这也是为了便于扩展
但是我们知道，每个计算机系统的设计都是不一样的，尤其是数据库中，表的结构也是千差万别，每个字段的定义及其类型也是千变万化。那么如何将中间表的数据正确的导入现有系统中哪？这就需要验证和导入的设计了。
根据上图可知一种简单的设计是，根据给远洋提运单设计一个中间表，给陆路清单设计一个中间表，然后设计两个验证过程，分别对提运单表和清单表进行数据有效性验证，倒入系统。如果来了新的（例如：交通部提运单标准），我们只要在[浅述EDI--验证模型(1)]中增加这个定义导入中间表便可以了，不用重新编写程序。因为验证导入过程是针对中间表的验证导入，而接收是可以定义写入那个中间表的那个字段的，也就是针对中间表的接收，两者没有必然的联系。
但是，我们可以看出，尽管前台的工作是自由的，但是验证和导入，因为是写死的，仍然限制了其，扩展的可能性！
当，来了一种新的报文，远洋联合国船图标准哪？我们可以定义一个中间表接收，但是针对这个中间表的验证，和导入我们仍然需要修改程序，当然，如果只是把这个验证和导入的过程放在后台，工作量将小很多，但是，只要有修改增加，那也是限制了它的功能。
你也许会说，可以定义一批规则，根绝这些规则，验证中间表的每个字段！
是的，完全可以这样做。
可是这儿有一个问题仍然限制了这种扩展，就是数据转换的问题。
比如：原始报文
LA123'1'123'
LA123'2'100'
我们知道了，这个报文中LA123代表车号，1（2）代表序号，123（100）代表海关货物代码
那么我们可以接收到中间表T_TEMP中
车号 序号 货物代码
LA123 1 123
LA123 2 100
系统中
车号 序号 货物代码 货物名称
LA123 1 AA 煤炭
LA123 2 BB 铁矿砂
那么从123到AA，从100到BB的转换，就是一个数据转换的问题，即我们的系统中可能使自己定义的一批代码规则，与海关或其他的都不一样
而验证，就是要验证，是不是能够与我们的代码对应上
你又说了，可以做一个转换表，来处理这种情况，是的，这样做很好。可是仍然无法处理这种新的报文，远洋联合国船图标准哪？因为我不能预见所有的可能会导入报文，那些代码需要转换？如果定义规则，给他一个转换标志，但是用户又不知道，它对应我们系统中的那个表的代码（况且用户是非计算机专业的）。
而以上所叙述的，是我不做到通用的验证导入的原因
但是，我们应该朝着通用前进。
做了一个接口，前台的界面是一样的，只是验证导入不一样了，有什么不一样哪？我可以轻松的挂接一个后台的验证导入过程。只要判断一下，用户要验证那个报文，然后取得验证的中间表，。。。（一个单独的验证都过程）。
如果又来了一个联合国的进口清单，我只要在这个接口里再添加一针对进口清单中间表的验证导入过程，而无需修改前台。
