数据库设计中的继承

Question

我正在设计一个包含许多主要实体类型的新实验室数据库。

每个实体的表将包含该实体的所有类型（entity_id，created_on，created_by等）通用的字段。然后，我将使用具体继承（每个唯一的属性集使用单独的表）来存储所有剩余字段。

我相信这是每天通过实验室的标准数据类型的最佳设计。但是，我们经常有一个特殊的样本，这些样本通常伴随着原始者想要存储的特定值。

问题： 我应该如何为特殊（非标准）类型的实体建模？

选项1： 用于特殊领域使用的实体价值的
一个表（entity_id，attribute_name，numerical_value）将持有的所有数据进行任何特殊的实体。
+较少的表格。
-无法强制要求特定属性。
-必须将行转换（枢轴）为无效的列。

选项2： 严格的具体继承。
为每个单独的特殊情况创建单独的表。
+遵循所有其他规则
-只有几行的许多表的开销。

选项3： 使用不同用户下的特殊表进行具体继承。
将所有特殊表放在另一个用户下。
+将所有特殊表和标准表分开。
+更容易在列表中搜索通用标准表，而无需搜索所有特殊表。
-只有几行的许多表的开销。

Answer 1

实际上，您描述的设计（公用表以及特定于子类型的表）称为“类表继承”。

具体表继承将在子类型表中重复所有通用属性，并且您将没有像现在这样的超类型表。

我强烈反对EAV。我认为它是SQL反模式。这似乎是一个不错的解决方案，因为它需要较少的表，但是稍后您会感到头疼。您确定了几个缺点，但还有许多其他缺点。恕我直言，仅当引入新的子类型时绝对
不能 创建新表，或者子类型数不受限制（例如，用户可以临时定义新属性）时，才正确使用EAV 。

您有很多子类型，但是它们仍然是有限的，所以如果我做这个项目，我会坚持使用 Class Table Inheritance
。每个子类型的行数可能很少，但是至少可以确保每个子类型的所有行都具有相同的列，可以NOT NULL根据需要使用，可以使用SQL数据类型，可以使用引用完整性约束，等等。从关系的角度来看，这是比EAV更好的设计。

您没有提到的另一个选项称为序列化LOB。也就是说，为自定义属性的半结构化集合添加BLOB列。在该列中存储XML，YAML，JSON或您自己的DSL。您将无法使用SQL轻松地从该BLOB中解析出各个属性，您将不得不将整个BLOB取回应用程序，并在代码中提取出各个属性。因此在某些方面不太方便。但是，如果这满足您对数据的使用，那么这没什么问题。