我要说,以上所有答案在问题中提到的示例和几乎所有情况下都是正确的。
偶尔我会遇到单个表更好的情况。这种情况很少见,当它出现时,我会想知道是否需要围绕一个单体(中立)实体进行架构。我很快就放弃了这个想法——也许问问别人,但我没有充分陈述我的观点,我们只能回到一直以来的做法。
然后,事实证明,我太晚才意识到我应该制作一个中立实体类型的单个表。
以下是一个支持我的例子:
假设有两种实体类型:公司和人。一家公司通常由一个人拥有,但有时另一家公司拥有一家公司。
保持这个想法,并进一步补充,假设每个公司都有一个注册代理人负责创建公司。并且,进一步说明,注册代理人可以是一个人或另一家公司。
考虑到公司/子公司的所有者/父母可能是一个人或一家公司,您可能开始看到挑战所在。相比之下,如果只有人可以拥有公司,则您的所有权链接表非常传统,具有列: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)
因此,您需要执行相同的操作来获取代理而不是所有者。我知道这不是我们接受过的架构方法,但我非常有信心,我的解决方案消除了冗余数据,并使编码、管理和阅读更加容易。如果您坚持认为我错了,请告诉我。请建议如何使用单独的公司和个人实体表架构我的示例。干杯!