使用父/子方法時，每一行都包含對父級的引用。下表定義了一個用于在父/子關系中包含父行和子行的典型表：

	復制代碼
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