我应该担心用尽层次结构吗？

Question

当您要求另外两个之间的新层次结构化时，结果逐渐更长。例如，在2/5.6和2/5.7之间，只有2/5.6.1和其他4个组件路径。层次结构数据类型限制为800个字节，因此您不能永远重复此字节。再说一次，整数类型也受到限制，但在实践中这不是问题。我是否应该定期碎片环境，以使身高不会无界生长？

Answer 1

它被认为是一种“最佳实践” hierarchyid “附加”新ID，以便您不使用中间状态（例如 /2/5.6/）。如果你的 hierarchyid 是一个聚类的主键，然后对性能不利，它将导致页面分裂类似于A 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 是您的聚类索引，这将 杀 按页面拆分性能。如果您想按父母对节点进行排名，则 使用排名列 反而;这很容易 和 更有效地从以后排序 SELECT 比在你期间要做的 INSERT 您必须担心交易隔离和其他此类头痛的地方。