我要说，以上所有答案在问题中提到的示例和几乎所有情况下都是正确的。
偶尔我会遇到单个表更好的情况。这种情况很少见，当它出现时，我会想知道是否需要围绕一个单体（中立）实体进行架构。我很快就放弃了这个想法——也许问问别人，但我没有充分陈述我的观点，我们只能回到一直以来的做法。
然后，事实证明，我太晚才意识到我应该制作一个中立实体类型的单个表。
以下是一个支持我的例子：
假设有两种实体类型：公司和人。一家公司通常由一个人拥有，但有时另一家公司拥有一家公司。
保持这个想法，并进一步补充，假设每个公司都有一个注册代理人负责创建公司。并且，进一步说明，注册代理人可以是一个人或另一家公司。
考虑到公司/子公司的所有者/父母可能是一个人或一家公司，您可能开始看到挑战所在。相比之下，如果只有人可以拥有公司，则您的所有权链接表非常传统，具有列：OwnershipID（有点不必要），CorporationID，PersonID。
相反，您需要像这样的内容：OwnershipID，CorporationID，OwnerID，OwnerType。不管怎样，您都可以使其正常工作，但至少不会很有趣。
继续我的例子，您需要为每个公司分配代理人。通常，代理人是所有者之一（一个人）。在这种情况下，您确实希望链接回该人的一个记录。您不希望将该人的记录作为所有者再次作为代理人（在代理表中）。那将是多余的。坏事会发生。 :-)
类似于“问题”，注册代理人也可以是公司，例如法律公司，会计师事务所或Biz Filings公司等典型示例。就像代理人-人一样，代理人-公司也不应该得到自己的记录。它需要链接回已经存在的公司表中的其企业实体的记录。[除了我最终说要
不有一个公司表]
就像匹配每个公司与其任何类型的所有者（人或公司）的链接表一样，您
可以拥有一个代理链接表：AgentRepresentationID，CorporationID，AgentID，AgentType...但是，当您必须汇总相关代理时，从Person表中获取一些代理和从Corporation表中获取一些代理时，它会很丑陋（在我看来）。
因此，在这种情况下，您可以看到中立实体类型的优势。它将是这样的：
表格：EntityAll
关键列：
EntityID，
EntityType（或EntityTypeID，如果您坚持的话，请链接以获取说明），
EntityName（名称和不同类型存在问题...超出本帖范围）
链接表：CorporationOwnership
关键列：
OwnershipID（再次强调这有点不必要），
ChildEntityID（被拥有的实体；为了清晰起见命名为“Child”，我不会这样命名），
ParentEntityID（父实体）
链接表：AgentRepresentation
关键列：
AgentRepresentationID（我不会说它），
CorporationEntityID（代表公司实体），
AgentEntityID（来自实体表，相当于代理记录的实体）
虽然您可能对我的架构感到满意，但是您应该对链接表中的列命名感到有些困扰。它让我感到困扰。通常，这些表中的第二个和第三个列名与您在每个实体的相应表中JOIN的列名完全匹配（哈哈，但是每个实体都没有相应的表，因此您不能使链接表列名与源列名匹配，因为它们是相同的列）。从技术上讲，这并不重要，但它会破坏您的命名约定，这应该很重要，但不足以不这样做。
如果我还没有充分说明，这是如何将其整合在一起的。您可以在EntityAll表格上JOIN自身以获取所需内容。
列出所有公司及其所有者（在T-SQL中）：
SELECT Corp.EntityName as CorpName, Owner.EntityName as OwnerName
FROM EntityAll as Corp
JOIN CorporationOwnership as Link on (Corp.EntityID = Link.ChildEntityID)
JOIN EntityAll as Owner on (Link.ParentEntityID = Owner.EntityID)
因此，您需要执行相同的操作来获取代理而不是所有者。我知道这不是我们接受过的架构方法，但我非常有信心，我的解决方案消除了冗余数据，并使编码、管理和阅读更加容易。如果您坚持认为我错了，请告诉我。请建议如何使用单独的公司和个人实体表架构我的示例。干杯！
