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

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

数据库物理模型设计的其他模式

除了上面提到的四种主要设计模式，还有一些其他模式，在某些项目中可能会用到，在这里先简单做个说明，暂不做深入讨论，等到以后的项目用到这些模式的时候，再结合实际需求详细解说。
（一）继承模式
继承模式，可以看作是“主从模式”的一种特殊情况（或者说是“变形”），它所代表的两个对象也是“一对多”的关系。它与“主从模式”的区别是，“继承模式”中从表的主键是复合主键，并且复合主键中必定包含主表的主键列。
根据从表继承主表的列的数量，继承模式又分以下两种情况：
1. 从表继承主表的全部列



在这种情况下，从表除了代表自身的专用字段以外，还冗余了主表的全部字段。这种设计方式的缺点显而易见：

数据冗余度大

一致性差

磁盘存储量大

它的优点也显而易见：

正因为它的冗余度大、所以它不易丢失数据。假设主表数据丢失、或者被误操作删改，也能依据从表数据重新生成主表数据；这种设计方式，可以在发生数据损坏的时候从应用的角度进行一定程度的数据恢复，等于是在SQL Server数据库级别的数据恢复功能之上又加了一道保险。

正因为它一致性差、主表数据被重复存储，所以可依据外键关系进行数据验证。将主从表记录作关联比较，如果数据不一致，就可以得知数据要么被人为改动，或者要么程序代码中存在bug。

尽管磁盘存储量大，但是数据在查询统计的时候，只需针对从表进行搜索即可，无需关联操作，可以加快检索的速度。这就是数据库模型设计中经常提到的“以空间换时间”。

2. 从表只继承主表的主键列



这种设计方式，从表只继承了主表的主键列，这种方式的优缺点与前面刚好相反。
优点：

数据冗余度小

一致性高

磁盘存储量小

缺点：

正因为它的冗余度小、所以它易丢失数据。假设主表数据丢失、或者被误操作删改，就只能通过SQL Server数据库级别的数据恢复操作来找回丢失的数据了。

正因为它一致性高，所以无法进行应用程序级的数据验证。

由于采用了一致性设计，磁盘存储量较小，但是数据在查询统计的时候，必须要对两个表进行内连接（INNER JOIN）操作，才能搜索到相关数据。而内连接操作时需要耗费一定的时间的。这就是数据库模型设计中经常提到的“以时间换空间”。

当然，在实际的数据库模型设计过程中，还会有介于上述两者之间的第3种情况出现，那就是从表继承了主表的主键列以及部分其他列。这就要求我们设计人员要依据实际的业务需求进行综合分析、权衡、折中，给出最符合业务需求的设计结果。
文章来源:http://blog.csdn.net/liu7537/archive/2006/04/13/661838.aspx