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