从原表中，我们可以很清晰地分出几块：

1、  车辆信息（型号、底盘号码等等）。

2、  物流信息（进库日期、销售日期、调拨日期等等）。

3、  客户信息（购车用户、手机号码等等）。

4、  销售信息（销售价格、终端价等等）。

5、  退货信息（退货原因等）。

6、  供货商信息（供货商名称）。

 

把前面的表设计完之后，接下来就开始设计进存销数据表了。

在讲解数据表之前，应先要把流程理清楚。我们可以这样设想：

录入了汽车基础信息之后，然后第一次进库（采购进库）。接下来，就有2种处理方式：调拨到别的分店（调拨出库）、销售给客户（销售出库）；如果分店卖不出去，自然就把它再返回给总店（调拨进库），而客户取消订单或者返修什么的，自然就退货了（退货进库）。

 

先说采购进库表。显然，前面已经录入汽车信息了，如果仍然是每次只能进库一个产品，估计仓管一定保证不打死你。为此，应该在车辆信息加上一个“选择”的是否字段，这样批量进库录入就方便多了。

采购进库表的字段并不难确定：进库ID，进库日期，操作人，底盘号码，备注。基于同样原因，可以再加上一个选择字段。

同样地，调拨出库表的字段也类似，不过由于调拨的是二级分销商，因此，还需要加上调往单位ID，因此，最终字段是：出库ID，调拨出库日期，操作人，底盘号码，调往单位ID，备注，选择。

与调拨出库对应的调拨进库表，显然只需要把相应的出库字段改为进库即可。

销售信息表嘛，就在这调拨出库表的基础上加上一些价格信息，客户ID，以及票证信息等等，以便查询。

退货进库表与采购进库表区别并不大，只是在这基础上加上一个退货原因，以便查询和改善客户满意度。

 

为什么数据库里的表跟上面的并不一致呢？是的，上面讲的是理论上的设计，不过，是否就这样设计应该从实现方式出发。

 

前面说过，如果分散成这么多个表，那么计算库存时则必须使用联合查询再进行加减，因此我们改为实时方式来显示，以减少运算。也就是说，进库表有多少就是多少库存。

这样一来，那么一个进库表就可以解决了。而为了区分进库的类型（采购进库、调拨进库和退货进库），还需要加上一个进库类型字段。

显然，可以用同样的方式建立起出库表。也许有人会说了，销售明细表和调拨出库表不是有相关信息了吗？然而，出于汇总的考虑，建议还是加上吧。

 

机智如你，肯定发现了这个问题：销售出库表，有一个退货进库表与之对应，而调拨出库却是“形影相吊，茕茕孑立”。

为什么呢？答案很简单。因为实际业务中，调拨进库只能退回总店，而不能在二级分销商之间互相调拨。因此，只需要进库时在进库表里追加数据，并更新汽车信息表中的调拨进库时间，然后删除调拨出库相应的记录即可，而没必要建立一个调拨进库表。当然更加不应该增加一个调出单位字段了。

根据实际情况建立表间关系。这里并没有把所有表都在关系视图里建立关系，例如汽车信息表和销售信息表等，如果非要创建，它们则属于一对一，且应该选择左联接方式。另外，值得注意的是，这里的关系全部都取消了级联更新和级联删除。这两个属性是有利有弊：

好处在于可以维护数据完整性，减少操作查询，例如，对于员工信息系统来说，可以考虑，这样的话，当员工离职后即可删掉相应的数据，而不必担心漏掉什么。

坏处当然也是因为这个了。如果不希望因为主表数据的更改导致其他历史数据发生变化，则应该取消它。真可谓“成也萧何败萧何”。

 

表的讲解到此结束。其它影响不太大的表（例如车厢挂靠表、库存奖励表等等）这里不再赘述，请自行参考源文件。