在SQL中，我有一个表设置
RegisterTable
----
DocId int
status int
docType intCarDocument Table
----
carDocId int (PK, FK -> RegisterTable)
name string
carMake varcharEmployeeDocument
----
emplyeeDocId int (PK, FK -> RegisterTable)
name varchar
age int这是一个关于文档的数据库。表的设计与问题无关。所以我有不同的文档Cars/Emplyee/etc ... --它们都有完全不同的字段集，无关。
我需要这些文档的元数据，它在RegisterTable中表示。这些元数据在文档之间是相似的。所以它有点像继承。
这个案例的数据库设计是什么？目前我做了三个独立的表，并创建了从CarDocument/EmployeeDpcument到RegisterTable的一对一关系。
当我创建文档时，我首先在RegisterTable中创建它的元数据，然后获取密钥并使用它在相应的CarDocument或EmployeeDocument表中创建文档。
这是可行的，但在我看来很麻烦。
额外信息：我有10 - 20个不同的文档表。我使用typeorm作为我的ORM解决方案。
研究：与Table has one to one relationship with many tables相似
我的设计可以工作，但是RegisterTable有点假，因为它包含了所有的docId。对于这种情况，哪一种是最好的DB设计？
3条答案
按热度按时间bq3bfh9z1#
Postgres实际上执行继承-请参见https://www.postgresql.org/docs/current/tutorial-inheritance.html
除此之外，如果您的元数据在不同类型的文档中总是相同的，那么原则上，您的方法是使元数据表与文档表具有关系（参见下文）。
元数据表本身不需要知道引用它的表。查询逻辑可以从docType和docId派生正确的辅助文档。
对于您的特定情况，正如您在上面发布的，如果单个“status”字段是您在该表中保存的唯一实际元数据，我认为您最好将该字段添加到文档表中。只有当您有一组固定的元数据，并且不想在许多不同的表中复制时，将其拆分到自己的表中才有意义。
nwnhqdif2#
我看不出你的设计有什么问题。无论如何，关键的一点是决定你是为所有的实体/表共享ID（就像你正在做的那样）还是拥有单独的ID。第二种选择可能更整洁和灵活。你会得到这样的结果：
当然，您也可以只使用一个包含许多字段的大表，根据docType填充（或不填充）每个字段，并且可能对每个不同的docType使用不同的语义（不，我开玩笑的，不要这样做）。
d6kp6zgx3#
有一个更灵活和可扩展的方法可以使用。
单个表存储所有文档元数据，然后为每个文档类型存储另一个单独的表，该表存储该文档类型的特定详细信息。
RegisterTable可以重命名为DocumentMetadata，并且包含DocId、status、docType等。CarDocument和EmployeeDocument表包含特定于每种类型（如carMake和age）的列。可以通过外键将表从
DocumentMetadata表绑定到特定于文档的表它不仅更加灵活，因为您可以不断添加新类型的文档，而且还可以避免创建没有任何真实的信息的无意义的表（RegisterTable）