当您在其他两个之间请求新的 HierarchyID 时,结果会逐渐变长。例如,在 2/5.6 和 2/5.7 之间只有 2/5.6.1 和其他 4 个组件路径。HierarchyID 数据类型限制为 800 个字节,因此您不能永远重复此操作。再说一次,整数类型也是有限的,但在实践中这不是问题。我是否应该定期整理我的表格以使高度不会无限增长?
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
是您的聚集索引,这将通过页面拆分来降低性能。如果您尝试按父节点对节点进行排名,请改用排名列;与在您不得不担心事务隔离和其他此类问题的情况下相比,从较晚进行排序更容易、更有效。SELECT
INSERT
于 2010-05-15T14:47:49.170 回答