hierarchyid 和 父\子

父/子

使用父/子方法时，每一行都包含对父级的引用。下表定义了一个用于在父/子关系中包含父行和子行的典型表：

	复制代码
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