如何在数据库中表示继承？[关闭]

第三个选项是创建一个“Policy”表，然后创建一个“SectionsMain”表，该表存储各部分类型中共有的所有字段。然后，为每种类型的部分创建其他表，这些表仅包含不常见的字段。

决定哪个最好主要取决于你有多少个字段以及你想如何编写你的 SQL。它们都会起作用。如果你只有几个字段，那么我可能会选择#1。对于“很多”字段，我会倾向于 #2 或 #3。

我倾向于方法 #1（一个统一的 Section 表），以便有效地检索整个策略及其所有部分（我认为您的系统会做很多事情）。

此外，我不知道您使用的是哪个版本的 SQL Server，但在 2008+ 中，稀疏列有助于在列中的许多值为 NULL 的情况下优化性能。

最终，您必须决定策略部分的“相似程度”。除非它们有很大差异，否则我认为更规范化的解决方案可能比它的价值更麻烦......但只有你能打这个电话。:)

根据提供的信息，我将数据库建模为具有以下内容：

政策

• POLICY_ID（主键）

负债

• LIABILITY_ID（主键）
• POLICY_ID（外键）

性能

• PROPERTY_ID（主键）
• POLICY_ID（外键）

...等等，因为我希望策略的每个部分都有不同的属性。否则，可能会有一个表，除了 之外，还会有一个 ...SECTIONSpolicy_idsection_type_code

无论哪种方式，这都允许您支持每个策略的可选部分...

我不明白你对这种方法有什么不满意的地方 - 这就是你存储数据的方式，同时保持引用完整性而不是复制数据。该术语是“规范化”的......

因为SQL是基于SET的，所以它与过程/OO编程概念相当陌生，并且需要代码从一个领域过渡到另一个领域。ORM 经常被考虑使用，但它们在大容量、复杂的系统中效果不佳。

@Bill Karwin 在他的 SQL 反模式一书中描述了三种继承模型，当时他提出了 SQL Entity-Attribute-Value 反模式的解决方案。这是一个简短的概述：

单表继承（又称每个层次结构的表继承）：

使用第一个选项中的单个表可能是最简单的设计。如前所述，许多特定于子类型的属性必须在这些属性不适用的行上指定一个值。使用此模型，您将有一个策略表，如下所示：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

但是，此模型也有一些缺点：

• 常见属性与子类型特定属性混合在一起，并且没有简单的方法来识别它们。数据库也不会知道。

• 定义表时，必须重复每个子类型表的通用属性。那绝对不是干枯的。

• 无论子类型如何，搜索所有策略都变得困难，并且需要一堆 s。UNION

这就是您必须查询所有策略的方式，无论类型如何：

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

• 现在，无论子类型如何，搜索所有策略都变得非常容易：不需要 s - 只需一个 .UNIONSELECT * FROM policies

我认为在大多数情况下，类表方法最合适。

---

这三个模型的名称来自 Martin Fowler 的《企业应用程序架构模式》一书。

另一种方法是使用组件。例如：INHERITS

CREATE TABLE person (
    id int ,
    name varchar(20),
    CONSTRAINT pessoa_pkey PRIMARY KEY (id)
);

CREATE TABLE natural_person (
    social_security_number varchar(11),
    CONSTRAINT pessoaf_pkey PRIMARY KEY (id)
) INHERITS (person);


CREATE TABLE juridical_person (
    tin_number varchar(14),
    CONSTRAINT pessoaj_pkey PRIMARY KEY (id)
) INHERITS (person);

因此，可以定义表之间的继承。

此外，在 Daniel Vassallo 解决方案中，如果您使用 SQL Server 2016+，我在某些情况下使用了另一种解决方案，而不会造成相当大的性能损失。

您只需创建一个仅包含公共字段的表，然后添加一个包含所有子类型特定字段的 JSON 字符串的列。

我已经测试了这种设计来管理继承，我对可以在相关应用程序中使用的灵活性感到非常高兴。

或者，考虑使用原生支持丰富数据结构和嵌套的文档数据库（例如 MongoDB）。