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

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

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

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

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

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

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

 

我们先把较为清晰的分离出来：客户信息、供货商信息和车辆信息。

 

客户信息表的基本字段设置如下：

客户名称、手机号码、固定电话、地址、邮政编码、联系人（如果仍需要更细化，则根据实际来增加字段）。

这样设置就够了吗？当然不是了。主键呢？有些新手可能会说，客户名称呀。

如果同一个客户，由不同的联系人来购买的时候怎么办？联合主键啊。这自然没问题，问题是，这样会不会太复杂了呢？其实，用一个客户ID字段（自动编号）设置为主键就可以解决这个问题了。

供货商信息设置类似，不过由于供货商有业务来往，因此可以加上开户行等字段，这里不再赘述。

 

车辆信息字段设置。将底盘号码、型号、发动机型号等属性设为字段，是毫无疑问的。这里需要详细说明的是几点：

1、  外键的设置。为了区分哪辆车是哪个供货商提供的，供货商ID（有重复索引）显然是不二之选，由此建立起一对多的关系。

2、  关于冗余字段。仔细留意，你会发现这个表并不符合第三范式。例如，验车员并不依赖于车辆信息而存在。再如，进库日期、调出日期、调入日期等等几个日期字段更不用说了。

 

先说验车员字段。如果按第三范式，这个字段显然应该被剔除出去。那么，把验车员跟车辆信息联系起来不外乎两个方法：

a、  建立一个验车记录表。

b、  以验车员ID作为外键，与职员表建立一对多关系。

增加一个表，对数据库体积的影响还是比较大的，这就要考虑其必要性了。也就是说，这个表的重要性到底有多大，才是建表的先决因素。很明显，相较之下，b方法更佳。

但我还是弃用，而是直接使用了验货员姓名字段。为什么呢？

这时候，我们就应该从业务和技术层面上来理解了。

如果使用b方法，那么很多查询，你都不得不连上职员表。——你总不能让用户记住每个验车员的ID吧？另外在窗体的查询条件上，设置控件也是个问题，你不得不使用2列组合框，代码也更加复杂。我们没必要为了完全遵循第三范式而把问题复杂化，是吧？

 

同样地，增加那几个日期字段，也是出于业务的考虑的。

这几个均属于流水记录信息。为这几个字段设置采购进库表、调拨出库表、调拨进库表、销售出库表和退货进库表，自是没问题，甚至可能更加清晰。但是必须要考虑到：

a、  库存计算。由于表较多，因此库存计算时，必须按进库和出库两类进行联合查询，然后再相减，从而得到实际库存。

b、  重复计算。假定某辆车进库后调拨到分销，分销卖不出去，退回总部，总部卖出去，又被退货……那么，在设计查询时，就得留意这个问题，以免一辆车被统计多次。

如果我们只关注结果，而不太关心过程的话，那么就可以增加这几个冗余字段来代替这几个表。实现思路：对车辆的每个过程更新对应的日期字段，来表示其当前状态。

 

事实上，这些应该在需求分析时就要考虑的了。例如，增加“选择”字段，可以为了方便用户操作。再如，库存计算。像上面那样的设置和计算是一种方法。另一种方法就是只设置一个进库表，只要出库（例如调拨出库、销售出库）就更新记录。也就是说，进库表就是实时库存表。不过，这样一来，当返修情况较多时，就不方便统计数据以便改善了。

 

表字段设计，既要考虑到业务需求，又要考虑技术可行性。其中技术层面是短板。即便有完整的开发团队，仍不能保证所有需求都能实现。因此，对于不太合理的业务，应该在管理上加以改善。软件只能优化流程，无法管理企业。