父/子
使用父/子方法时，每一行都包含对父级的引用。下表定义了一个用于在父/子关系中包含父行和子行的典型表：
|
|
|
|---|---|
USE AdventureWorks2008R2 ;
GO
CREATE TABLE ParentChildOrg
(
BusinessEntityID int PRIMARY KEY,
ManagerId int REFERENCES ParentChildOrg(BusinessEntityID),
EmployeeName nvarchar(50)
) ;
GO
|
|
针对一些常见操作比较父/子与 hierarchyid
-
使用
hierarchyid
进行子树查询时速度明显加快。
-
使用
hierarchyid
进行直接后代查询时速度稍慢。
-
使用
hierarchyid
移动非叶节点时速度明显减慢。使用
hierarchyid
插入非叶节点和插入或移动叶节点具有相同的复杂度。
当存在以下情况时，使用父/子可能更好：
-
键的大小非常重要。在节点数相同的情况下，
hierarchyid
值等于或大于整型系列（
smallint
、
int
、
bigint
）的值。这只是在很少情况下使用父/子的一个原因，因为
hierarchyid
在 I/O 局部实用性和 CPU 复杂性方面明显优于使用父/子结构时所需的公用表表达式。
-
很少跨层次结构的不同部分执行查询。也就是说，是否通常仅对层次结构中的单个点进行查询。在这些情况下，存储在一起并不重要。例如，如果组织表仅用于为各个雇员运行工资单，则使用父/子更好。
-
非叶子树移动频繁并且性能非常重要。在父/子表示形式中，更改层次结构中行的位置将影响单个行。使用
hierarchyid
时，更改行的位置将影响
n
行，其中
n
是要移动的子树中的节点数。
如果这种非叶子树移动频繁并且性能非常重要，但多数移动操作都是在比较明确的层次结构级别上进行的，请考虑将较高和较低的级别拆分成两个层次结构。这样，所有的移动操作都是移到较高层次结构的叶级。例如，假设有一个由服务承载的网站的层次结构。各网站包含许多以分层方式排列的页面。承载的网站可能移动到网站层次结构中的其他位置，但是从属的页面很少会重新排列。这种情况可表示如下：
复制代码
CREATE TABLE HostedSites ( SiteId hierarchyid, PageId hierarchyid ) ; GO
