可变属性的需求：我们需要在数据库里面存储很多电器，比如电视，冰箱等等。通常，在程序中，我们的类图为：
EVA设计
对于这种继承下来的可变属性时，有一种办法是创建另外一张表，将属性当成行来存储。
其中存储的数据类似下面这样：
这样的设计称为：实体-属-值，简称：EVA，或者又叫开放架构、无模式。
这种设计有如下3种好处：
1、这两张表的列都很少。
2、新增的属性不会对现有的表结构造成影响，不需要新增列。
3、避免由于空值而造成的表内容混乱。
但是这样也有如下缺点:
1、查询属性
本来，我们想要按出厂日期查询，只需要：
SELECT ElectricId,DateOfManufacture FROM Electric
但是这种方式不行，它需要这样：
SELECT ElectricId,AttrValue AS 'DateOfManufacture' FROM Attribute WHERE AttrName = 'DateOfManufacture'
2、无法声明强制属性
本来，我们要确保DateOfManufacture(出厂日期)这个属性有值，在传统数据库设计中，只需要很简单的声明一个NOT NULL就OK了。
但是现在在EVA设计中，每个属性对应的是Attribute中的一行。我们需要建立一个约束来检查对于每个ElectricId都存在一行，并且这行的AttrName是DateOfManufacture。并且这行记录的AttrValue不为空，并且符合日期格式。
3、无法使用SQL的数据类型
由于AttrValue的格式只能声明为Varchar或NVarchar类型，因此用户输入的日期格式可能是各种各样，甚至有的根本就不是日期格式。
由于数据类型不能够由限制，因此我们执行如下SQL语句也不会报错。
INSERT Attribute VALUES(1,'DateOfManufacture','我不是一个日期') --这样的语句也不报错
4、无法确保引用完整性
加入上面的设计，我们需要添加一个品牌属性。可选值必须是存在的比如，三星，康佳，海尔等等。在传统的数据库设计中，我们只需要设计一张品牌表，并给本表添加一个品牌Id字段，建立外键约束就可以了。
但是，在EVA设计中，因为品牌属性对应的是一行，因此我们无法使用外键来确保引用完整性。如果我们不处理，那么用户输入的品牌属性的值可能是不存在的。
5、重复记录
在EVA设计中，我们可能将同一个属性了两次。
因为，我们连续执行如下SQL语句两次也是不报错的：
INSERT Attribute VALUES(1,'DateOfManufacture','2013-09-09') INSERT Attribute VALUES(1,'DateOfManufacture','2013-09-10')
由于可能存在重复记录，因此我们按出厂日期统计出厂产品数量也并不可靠。同时，按日期统计，也很复杂。
SELECT ElcDate, COUNT(*) AS Per_Date FROM (SELECT DISTINCT ElectricId,AttrValue AS ElcDate FROM Attribute WHERE AttrName = 'DateOfManufacture') GROUP BY ElcDate
这是Oracle中的写法。
6、重组列
在传统数据库设计中，加入我们要显示一条完整的记录，我们只需要:
SELECT * FROM Electric
但是现在，我们要：
SELECT i.ElectricId, i1.AttrValue AS 'Name', i2.AttrValue AS 'DateOfManufacture', i3.AttrValue AS 'Screen' FROM Electric AS i LEFT OUTER JOIN Attribute AS i1 ON i.ElectricId = i1.ElectricId AND i1.AttrName='Name' LEFT OUTER JOIN Attribute AS i2 ON i.ElectricId = i2.ElectricId AND i2.AttrName='DateOfManufacture' LEFT OUTER JOIN Attribute AS i3 ON i.ElectricId = i3.ElectricId AND i3.AttrName='Screen'
不在多说，总而言之，以上的设计，并非一个非常耐得住推敲的设计。
解决方案
一、单表继承
单表继承的设计是将所有相关的类型都存在一张表中，为所有类型的所有属性都保留一列。同时使用一个属性来定义每一行表示的子类型。
例如，对于以上电器的需求，单表继承的数据设计如下：
单表继承的方式可以理解为，所有子类的字段，都往单表里放，存储的时候，当某子实体没有的时候，相应的类为空，都是预留一列作为标记类型。
单表继承的缺点就是：
- 列过多。
- 过多NULL值。
- 当要增加属性的时候，要改动表结构。
综上所述：单表继承只是适合使用子类的特殊属性列不多的情况。
二、实体表继承
实体表继承可以理解为：子表在设计的时候，将父表的所有的属性全部都在本表定义多一次。
回到上面的例子，如果用实体表继承的话，对应的设计如下：
实体表继承相比于单表继承，有一个好处，就是防止在一行内存储太多和当前子类型无关的属性。比如在冰箱表里没有了屏幕列，而在单表继承中，是由Scree列的NULL值的。另外，也不用在加多一个列用于标记当前是什么电器。
实体表继承的致命缺点：
重复列过多
重复列过多，很容易让人摸不着头脑。
三、类表继承
我的推荐，我最喜欢，我认为最可靠的方式
类表继承模拟了高级程序语言中的继承，把表当成面向对象里的类。创建一张基表，包含所有子类型的公共属性。对于每个子类型，创建一个独立的表，通过外键和基类表相连。
对以以上例子，类表继承的设计如下：
类表继承，相比于实体类继承，明显的有点在于，少了很多重复列。子类表中，主键同时也是外键。
我认为这是一个比较好的方法。
四、半结构化
半结构化，实际上跟单表继承差不多。单表继承是多个列，而半结构化使用一个新特性，比如一个xml类型的列，来存储子类的属性。
对于以上例子，半结构化的设计如下：
子类的信息，存在一个XML列中，你爱设置什么节点就什么节点。反正查询起来也不麻烦。不够要记住的是，要有一个Type列，来标记哪行是哪种电器。不然就全乱套了。
由于，现在SQLServer对XML的支持越来越强大，这也是一个不错的选择。
