我正在设计一个包含许多主要实体类型的新实验室数据库。
每个实体的表将包含该实体的所有类型（entity_id，created_on，created_by等）通用的字段。然后，我将使用具体继承（每个唯一的属性集使用单独的表）来存储所有剩余字段。
我相信这是每天通过实验室的标准数据类型的最佳设计。但是，我们经常有一个特殊的样本，这些样本通常伴随着原始者想要存储的特定值。
问题： 我应该如何为特殊（非标准）类型的实体建模？
选项1： 用于特殊领域使用的实体价值的 一个表（entity_id，attribute_name，numerical_value）将持有的所有数据进行任何特殊的实体。 +较少的表格。 -无法强制要求特定属性。 -必须将行转换（枢轴）为无效的列。
entity_id
attribute_name
numerical_value
选项2： 严格的具体继承。 为每个单独的特殊情况创建单独的表。 +遵循所有其他规则 -只有几行的许多表的开销。
选项3： 使用不同用户下的特殊表进行具体继承。 将所有特殊表放在另一个用户下。 +将所有特殊表和标准表分开。 +更容易在列表中搜索通用标准表，而无需搜索所有特殊表。 -只有几行的许多表的开销。
实际上，您描述的设计（公用表以及特定于子类型的表）称为“类表继承”。
具体表继承将在子类型表中重复所有通用属性，并且您将没有像现在这样的超类型表。
我强烈反对EAV。我认为它是SQL反模式。这似乎是一个不错的解决方案，因为它需要较少的表，但是稍后您会感到头疼。您确定了几个缺点，但还有许多其他缺点。恕我直言，仅当引入新的子类型时绝对 不能 创建新表，或者子类型数不受限制（例如，用户可以临时定义新属性）时，才正确使用EAV 。
您有很多子类型，但是它们仍然是有限的，所以如果我做这个项目，我会坚持使用 Class Table Inheritance 。每个子类型的行数可能很少，但是至少可以确保每个子类型的所有行都具有相同的列，可以NOT NULL根据需要使用，可以使用SQL数据类型，可以使用引用完整性约束，等等。从关系的角度来看，这是比EAV更好的设计。
NOT NULL
您没有提到的另一个选项称为序列化LOB。也就是说，为自定义属性的半结构化集合添加BLOB列。在该列中存储XML，YAML，JSON或您自己的DSL。您将无法使用SQL轻松地从该BLOB中解析出各个属性，您将不得不将整个BLOB取回应用程序，并在代码中提取出各个属性。因此在某些方面不太方便。但是，如果这满足您对数据的使用，那么这没什么问题。
