[导入]数据库物理模型设计的其他模式之单表模式

连载之9
原创：胖子刘（转载请注明作者和出处，谢谢）

（三）单表模式
单表模式，就是把相关子类的属性统统集中在一个表里，通过“类别”字段来区分表内记录所属的子类以及该类的有效属性。在实际案例当中，单表模式的应用还是很广泛的。举个例子，有车的朋友现在拿出你们的《中华人民共和国机动车行驶证》，翻到“副页”，看看副页登记的档案指标。下图为推测设计图、不代表真实设计。



我是2006年2月份买的车，我的机动车行驶证副页记载了如下档案指标：“号牌号码、车辆类型、总质量、整备质量、核定载质量、准牵引总质量、核定载客、驾驶室共乘、货箱内部尺寸、后轴钢板弹簧片数、外廓尺寸、检验记录。”浏览本文的朋友可以跟自己的行驶证对照一下，尤其是老司机，看看若干年前发的行驶证和现在的有没有区别。
在这里大家可以很清楚的看到，上述指标中“号牌号码、车辆类型、总质量、整备质量、外廓尺寸、检验记录”是各种类型的车辆的公共属性，“核定载质量、准牵引总质量、驾驶室共乘、货箱内部尺寸、后轴钢板弹簧片数”是货运车辆的专有属性，“核定载客”是客运车辆的专有属性。
根据经验我推测，就此种表现形式而言，公安机关交通管理部门的计算机系统应该就是采用“单表模式”进行的设计。通过这一个表就可以容纳包括货车、客车、轿车、摩托车、农用车等所有类型的车辆档案。这里面有一个“车辆类型”属性，这个属性就是用来区分当前记录所属类别，程序代码根据这个属性的值来确定当前档案记录的哪些属性是有效、且需要记录和打印的，哪些属性对当前记录来说是无效的。比如我行驶证上的车辆类型是“轿车”，除公共属性以外，只有“核定载客”指标打印了一个“5人”字样，其余指标打印的都是“--”字样，因为这些指标都是货车才有的，对轿车而言是无意义的。
这种设计有一个明显的好处——如果事先对车辆档案都有哪些指标调研的很充分，且后期基本上不需要扩展，那么系统运行时无论遇上什么类型的车辆档案都不需要变更程序，具有很强的通用性。很明显，行驶证是套打的，这种设计便于大批量的制作证件底单。因为不管什么类型的车辆档案都是这个格式，只要开动机器印刷便是。
凡事有利就有弊，这种设计的弊端也很明显。首先是给人的印象不是很人性化。我明明买的是轿车，你发给我的证件搞那么多货车的指标在上面干嘛？浪费版面！其次，如果一旦后期需要对某种类型的车辆档案扩充属性（无论你前期的需求调研多么充分，都不能保证以后不会变化），假设国家新颁布一部法规或者国标，要求必须在行驶证上记载客车的“发动机排量”、其他类型的车辆不作要求，那么按照这种设计，所有车辆（包括“无辜的”货车在内）都要换证（呵呵，不知道这种换证收不收工本费）！
声明：以上例子仅仅是我的推测，用以说明“单表模式”。我没有交通管理部门的工作经历，如果与实际情况不符，欢迎同行批评指正。
文章来源:http://blog.csdn.net/liu7537/archive/2006/05/09/713966.aspx