Sql server 具有非活动记录的employee表上的SQL hierarchyid（多个根节点）

对于那些将SQL hierarchyid用于员工表的人，如何容纳同一个表中包含的非活动（退休、终止）员工记录？在新CEO（root）的情况下，这会导致多行具有空parentID。将这些记录迁移到单独的表中是常见的做法吗

我们有一个包含活动和非活动记录的employee表。这对于许多使用员工数据但在员工离职后更新自身相关数据速度较慢的下游系统非常有用。例如，使用employee表跟踪项目经理的项目系统。如果这些系统引用一个只有活动雇员的表，那么在提取雇员数据时，它们将找不到匹配的行

问题澄清 为了澄清这个问题，我读过关于多根的文章，我意识到这是可能的。我的问题更多的是关于如何在实地处理这一问题。如前所述，一种选择是将非活动记录移动到单独的表中，以便根节点始终是单个CEO。另一个选项可能是“org”的伪根，后跟所有CEO记录（过去和现在）。或者您可以完全跳过“/”根，从所有CEO记录开始。我假设这种情况（具有活动/非活动CEO类型记录的员工表）很常见，所以我想知道正在使用哪些解决方案

源数据更新

---

仅供参考-源员工表位于我的系统的上游，我们从Active Directory源获取更新。我无法切换源以消除child\u id/parent\u id列。但是，我可以更新我们的副本，以包含我们下游应用程序的hierarchyid。我会在我们的数据中保留child\u id/parent\u id，这样我就可以使用提要来更新我们的副本

您可以这样做并维护历史层次结构的一种方法是为每个关系包含开始和结束日期。因此，有5名副总裁向首席执行官约翰汇报，约翰将于下个月离职。当新任首席执行官Dave上任时，这5名副总裁将向Dave汇报。您不需要更改整个层次结构

---

另一种方法是在顶部设置几个固定的头衔，只需将首席执行官的姓名从John更新为Dave（虽然我不建议这样做，但我已经看到了它的使用）。

不知道员工的身份与更改层级结构的根有什么关系。它们应该是两个不同的领域，因为它们处理不同的问题。将子树从一个节点移动到另一个节点（或从一个根移动到另一个根）并不是什么奇怪的事情，甚至在本文中也提到了这一点。最后，当您使用

HierarchyId

类型时，根本不需要

ParentID

字段。我还没有探讨HierarchyId维护的逻辑，但是从初始负载的角度来看，有多个子级和空父级似乎是一个问题。通常，员工层次结构中的根是没有父级的子级。对于一个活跃员工表，这将起作用，因为root用户将是单个CEO。如果表中同时包含当前和过去的CEO，则您有几个没有父级的子级可以被视为根。您假设每个表只能有一棵树。那是不对的。没有要求层次结构字段是唯一的，也没有要求每个表只有一棵树。没有什么能阻止你拥有多棵树，拥有多棵树也不是一个错误。另一方面，假设根处于活动状态是错误的，因为您使用一个字段来传递两种独立类型的信息。在开始考虑null和重构之前，您确实需要了解HierarchyID类型是如何工作的，以及子树是如何移动的。如果您允许HierarchyID不是唯一的，那么您不允许在只有单亲的子级上发生冲突吗？如果允许多个/3/2值，那么谁是/3/2/1的父级？我读过关于多棵树的文章，大多数人指出，虽然这是可能的，但并不是最理想的解决方案。我的假设是，这种情况（具有非活动根的employee表）并不少见，因此我想知道其他人在该领域是如何处理的。我将尝试通过更新来澄清这个问题。