实际上，您描述的设计（公用表以及特定于子类型的表）称为“类表继承”。
具体表继承将在子类型表中重复所有通用属性，并且您将没有像现在这样的超类型表。
我强烈反对EAV。我认为它是SQL反模式。这似乎是一个不错的解决方案，因为它需要较少的表，但是稍后您会感到头疼。您确定了几个缺点，但还有许多其他缺点。恕我直言，仅当引入新的子类型时绝对
不能 创建新表，或者子类型数不受限制（例如，用户可以临时定义新属性）时，才正确使用EAV 。
您有很多子类型，但是它们仍然是有限的，所以如果我做这个项目，我会坚持使用 Class Table Inheritance
。每个子类型的行数可能很少，但是至少可以确保每个子类型的所有行都具有相同的列，可以
NOTNULL根据需要使用，可以使用SQL数据类型，可以使用引用完整性约束，等等。从关系的角度来看，这是比EAV更好的设计。
您没有提到的另一个选项称为序列化LOB。也就是说，为自定义属性的半结构化集合添加BLOB列。在该列中存储XML，YAML，JSON或您自己的DSL。您将无法使用SQL轻松地从该BLOB中解析出各个属性，您将不得不将整个BLOB取回应用程序，并在代码中提取出各个属性。因此在某些方面不太方便。但是，如果这满足您对数据的使用，那么这没什么问题。
