0

当您在其他两个之间请求新的 HierarchyID 时，结果会逐渐变长。例如，在 2/5.6 和 2/5.7 之间只有 2/5.6.1 和其他 4 个组件路径。HierarchyID 数据类型限制为 800 个字节，因此您不能永远重复此操作。再说一次，整数类型也是有限的，但在实践中这不是问题。我是否应该定期整理我的表格以使高度不会无限增长？

4

1 回答 1

1

它被认为是“附加”新 ID 的“最佳实践”，hierarchyid因此您根本不使用那些中间状态（例如/2/5.6/）。如果您hierarchyid是集群主键，那么这对性能不利，它会导致页面拆分类似于意愿的方式uniqueidentifier。

如果您生成顺序子代，那么您就不太可能需要担心用完；每个父母都可以拥有数百万个孩子。

以下是您期望如何生成hierarchyid值的示例：

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION 
    UPDATE Hierarchy
    SET @LastChild = LastChild = HId.GetDescendant(LastChild, NULL)
    WHERE HId = @ParentID

    INSERT Hierarchy (HId, ...)
    VALUES (@LastChild, ...)
COMMIT

如果您以这种方式生成 id，请放心，您永远不必担心用完。

出于好奇，我进行了一次快速测试，以确定您可以走多远。这是一个测试脚本：

DECLARE
    @parent hierarchyid,
    @child hierarchyid,
    @high hierarchyid,
    @cnt int

SET @parent = '/1/'
SET @child = @parent.GetDescendant(NULL, NULL)
SET @cnt = 0

WHILE (@@ERROR = 0)
BEGIN
    SET @cnt = @cnt + 1
    PRINT CAST(@cnt AS varchar(10)) + ': ' + @child.ToString()
    SET @high = @parent.GetDescendant(@child, @high)
    SET @child = @parent.GetDescendant(@child, @high)
END

您可以在 1426 的点嵌套级别看到它出错，因此这是您可以创建多少“中间”节点的最坏情况限制，最坏情况意味着每个插入都在两个最深的节点之间 -嵌套节点。

正如我在评论中提到的，很难达到这个限制，但这仍然不是一个好主意。随着您使用越来越多的“点”，实际字节长度会变长，这会降低性能。如果它hierarchyid是您的聚集索引，这将通过页面拆分来降低性能。如果您尝试按父节点对节点进行排名，请改用排名列；与在您不得不担心事务隔离和其他此类问题的情况下相比，从较晚进行排序更容易、更有效。SELECTINSERT

于 2010-05-15T14:47:49.170 回答