@比尔·卡尔文在他的书中描述了三种继承模型SQL 反模式书上，在提出 SQL 的解决方案时实体-属性-值反模式。这是一个简短的概述：
单表继承（又名每层次结构表继承）：
在第一个选项中使用单个表可能是最简单的设计。正如您所提到的，许多特定于子类型的属性必须被赋予NULL这些属性不适用的行上的值。使用此模型，您将拥有一个策略表，如下所示：
+------+---------------------+----------+----------------+------------------+
| id | date_issued | type | vehicle_reg_no | property_address |
+------+---------------------+----------+----------------+------------------+
| 1 | 2010-08-20 12:00:00 | MOTOR | 01-A-04004 | NULL |
| 2 | 2010-08-20 13:00:00 | MOTOR | 02-B-01010 | NULL |
| 3 | 2010-08-20 14:00:00 | PROPERTY | NULL | Oxford Street |
| 4 | 2010-08-20 15:00:00 | MOTOR | 03-C-02020 | NULL |
+------+---------------------+----------+----------------+------------------+
\------ COMMON FIELDS -------/ \----- SUBTYPE SPECIFIC FIELDS -----/
保持设计简单是一个优点，但这种方法的主要问题如下：
-
当涉及到添加新的子类型时，您必须更改表以适应描述这些新对象的属性。当您有许多子类型或者您计划定期添加子类型时，这很快就会成为问题。
-
数据库将无法强制执行哪些属性适用，哪些不适用，因为没有元数据来定义哪些属性属于哪些子类型。
-
你也不能强制执行NOT NULL关于应该是强制性的子类型的属性。您必须在您的应用程序中处理这个问题，这通常并不理想。
具体表继承：
解决继承问题的另一种方法是为每个子类型创建一个新表，重复每个表中的所有公共属性。例如：
--// Table: policies_motor
+------+---------------------+----------------+
| id | date_issued | vehicle_reg_no |
+------+---------------------+----------------+
| 1 | 2010-08-20 12:00:00 | 01-A-04004 |
| 2 | 2010-08-20 13:00:00 | 02-B-01010 |
| 3 | 2010-08-20 15:00:00 | 03-C-02020 |
+------+---------------------+----------------+
--// Table: policies_property
+------+---------------------+------------------+
| id | date_issued | property_address |
+------+---------------------+------------------+
| 1 | 2010-08-20 14:00:00 | Oxford Street |
+------+---------------------+------------------+
这种设计将基本上解决单表方法所确定的问题：
-
现在可以强制执行强制属性NOT NULL.
-
添加新的子类型需要添加一个新表，而不是向现有表添加列。
-
也不存在为特定子类型设置不适当属性的风险，例如vehicle_reg_no房地产政策领域。
-
没有必要type属性与单表方法中相同。该类型现在由元数据定义：表名。
然而，这种模型也有一些缺点：
-
公共属性与子类型特定属性混合在一起，并且没有简单的方法来识别它们。数据库也不会知道。
-
定义表时，您必须为每个子类型表重复公共属性。那绝对不是DRY.
-
无论子类型如何，搜索所有策略都变得很困难，并且需要一堆UNIONs.
这是您必须查询所有策略（无论类型如何）的方法：
SELECT date_issued, other_common_fields, 'MOTOR' AS type
FROM policies_motor
UNION ALL
SELECT date_issued, other_common_fields, 'PROPERTY' AS type
FROM policies_property;
请注意，添加新的子类型将需要使用额外的内容来修改上述查询UNION ALL对于每个子类型。如果忘记此操作，很容易导致应用程序出现错误。
类表继承（又名每类型继承表）：
这是解决方案@David 在另一个答案中提到。您为基类创建一个表，其中包括所有公共属性。然后，您将为每个子类型创建特定的表，其主键也充当外键到基表。例子：
CREATE TABLE policies (
policy_id int,
date_issued datetime,
-- // other common attributes ...
);
CREATE TABLE policy_motor (
policy_id int,
vehicle_reg_no varchar(20),
-- // other attributes specific to motor insurance ...
FOREIGN KEY (policy_id) REFERENCES policies (policy_id)
);
CREATE TABLE policy_property (
policy_id int,
property_address varchar(20),
-- // other attributes specific to property insurance ...
FOREIGN KEY (policy_id) REFERENCES policies (policy_id)
);
该解决方案解决了其他两种设计中发现的问题：
-
强制属性可以通过以下方式强制执行NOT NULL.
-
添加新的子类型需要添加一个新表，而不是向现有表添加列。
-
没有为特定子类型设置不适当属性的风险。
-
无需type属性。
-
现在，公共属性不再与子类型特定属性混合。
-
我们终于可以保持干燥了。创建表时无需重复每个子类型表的公共属性。
-
管理自动递增id策略变得更容易，因为这可以由基表处理，而不是每个子类型表独立生成它们。
-
现在，无论子类型如何，搜索所有策略都变得非常容易：否UNION需要 - 只是一个SELECT * FROM policies.
我认为类表方法在大多数情况下是最合适的。
这三款车型的名字来源于马丁·福勒的 book 企业应用架构模式.
