適用於：
SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceMicrosoft Fabric 中的 SQL 資料庫
hierarchyid 資料類型是可變長度的系統資料類型。 您可以使用 hierarchyid 來代表階層中的位置。 類型為 hierarchyid 的資料行不會自動代表樹狀結構。 應用程式必須產生和指派 hierarchyid 值，讓資料列之間的所需關聯性反映在值中。
hierarchyid 資料類型的值代表樹狀目錄階層中的位置。 hierarchyid 的值具有下列屬性：
極其緊湊：在具有 n 個節點的樹中表示節點所需的平均位數取決於平均扇出（節點的平均子項數）。 對於小型扇出 （0-7），大小約為 6 * logA n 位，其中 A 是平均扇出。 在 100,000 人的組織階層中，平均扇出為六個層級的節點大約需要 38 位元。 然後，這會四捨五入成 40 位元 (或 5 個位元組)，以便進行儲存。
比較是深度優先的：給定兩個 階層值
ab和 ，a<b表示在樹的深度優先遍歷中，a 位於 b 之前。 hierarchyid 資料類型的索引採用深度優先順序，而且在深度優先周遊中彼此接近的節點會以彼此接近的方式儲存。 例如，某筆記錄的子系會儲存在該記錄旁。 如需詳細資訊，請參閱階層式資料 （SQL Server）。支援任意插入和刪除：透過使用 GetDescendant 方法，一律可以在任何指定節點的右側、任何指定節點的左側或任何兩個兄弟之間產生同層級。 在階層中插入或刪除任意的節點數目時，比較屬性會保留下來。 大部分的插入和刪除項目都會保留壓縮度屬性。 不過，兩個節點之間的插入會產生階層 ID 值，其表示法稍不緊湊。
編碼限制為 892 個位元組： 因此，其表示法中具有太多層級而無法容納 892 位元組的節點無法以 hierarchyid 類型表示。
階層 ID 類型可供共用語言執行階段 （CLR） 用戶端作為資料類型使用SqlHierarchyId。
Remarks
hierarchyid 類型會透過編碼從樹狀目錄根到節點的路徑，以邏輯方式編碼階層樹狀結構目錄中單一節點的相關資訊。 這類路徑會以邏輯方式表示成在根目錄之後造訪之所有子系的節點標籤序列。 此表示以斜線為開頭，而且只有造訪根目錄的路徑才會以單一斜線表示。 若為根目錄底下的層級，每個標籤都會編碼成以小數點隔開的整數序列。
子系之間的比較是透過按照字典順序比較以小數點隔開的整數序列加以執行。 每個層級後面都跟著一個斜線。 因此，斜線會分隔父代與其子系。 例如，下面是有效的 hierarchyid 路徑 (長度分別為 1、2、2、3 和 3 個層級)：
//1//0.3.-7//1/3//0.1/0.2/
您可以在任何位置插入節點。 在之後 /1/2/ 但在之前 /1/3/ 插入的節點可以表示為 /1/2.5/。 之前 0 插入的節點的邏輯表示法為負數。 例如，前面 /1/1/ 的節點可以表示為 /1/-1/。 節點不能有前導零。 例如， /1/1.1/ 有效，但 /1/1.01/ 無效。 若要避免發生錯誤，請使用 GetDescendant 方法來插入節點。
資料型別轉換
hierarchyid 資料類型可以轉換成其他資料類型，如下所示：
使用 ToString 方法將 hierarchyid 值轉換成邏輯表示法，做為 nvarchar （4000） 資料類型。
使用 CSharp 和 Write 來使用 Read （資料庫引擎） 將 hierarchyid 轉換為 varbinary。
若要透過 SOAP 傳輸 hierarchyid 參數，請先將它們轉換為字串。
升級資料庫
當資料庫升級至較新版本的 SQL Server 時，會自動安裝新的元件和 hierarchyid 資料類型。 Upgrade Advisor 規則會偵測任何具有衝突名稱的使用者類型或組件。 升級顧問建議重新命名任何衝突的元件，並重新命名任何衝突的類型，或在程式碼中使用兩部分名稱來參考該預先存在的使用者類型。
如果資料庫升級偵測到名稱衝突的使用者組件，它會自動重新命名該組件，並將資料庫置於可疑模式。
如果具有衝突名稱的使用者類型在升級期間存在，將不會採取任何特殊步驟。 升級後，舊使用者類型和新系統類型都存在。 使用者類型只能透過兩部分名稱使用。
在複寫資料表中使用 hierarchyid 資料行
hierarchyid 類型的資料行可以使用在任何複寫資料表上。 應用程式的需求會因複寫是單向或雙向，以及使用的 SQL Server 版本而不同。
單向複寫
單向複寫包括快照集複寫、交易式複寫和合併複寫，其中不會在訂閱者進行變更。 hierarchyid 資料行使用單向覆寫的方式會因訂閱者執行的 SQL Server 版本而不同。
SQL Server 發行者可以將 hierarchyid 資料行複寫至相同版本的 SQL Server 訂閱者，而不需要任何特殊考量。
SQL Server 發行者必須轉換 hierarchyid 資料行，才能將其複寫至執行 SQL Server Compact 或舊版 SQL Server 的訂閱者。 SQL Server Compact 和舊版 SQL Server 不支援 hierarchyid 資料行。 如果您使用其中一個版本，您仍然可以將資料複寫到訂閱者。 若要這樣做，您必須設定結構描述選項或發行集相容性層級 (用於合併式複寫)，如此資料行才能轉換成相容的資料類型。
在這兩種情況下都支援資料行篩選。 這包括篩選出 hierarchyid 資料行。 只要篩選不包含 hierarchyid 資料行，就支援資料列篩選。
雙向複寫
雙向複寫包括具有更新訂閱的異動複寫、點對點異動複寫，以及在「訂閱者」端進行變更的合併式複寫。 複寫可讓您使用雙向複寫的 hierarchyid 資料行來設定資料表。 請注意下列需求和考量。
發行者和所有訂閱者必須在 SQL Server 2016 （13.x） 或更新版本上執行相同的版本。
複寫會將資料複寫為位元組，而且不會執行任何驗證以確保階層的完整性。
在來源 （訂閱者或發行者） 所做的變更複寫至目的地時，不會維護其階層。
hierarchyid 直欄的值可以在所有資料庫中具有相同的二進位表示法。 當應用程式邏輯獨立為不同的實體產生相同的 階層 ID 時，雙向複寫中可能會發生衝突。 因此，雖然可以在「發行者」和「訂閱者」上產生相同的值，但是它可能會套用至不同的資料列。 複寫不會檢查此條件，而且沒有內建方式來分割 階層 資料行值，就像資料行一樣
IDENTITY。 應用程式必須使用條件約束或其他機制來避免發生這類無法偵測的衝突。插入在訂閱者上的資料列可能會孤立。 插入資料列的父資料列可能會在「發行者」中刪除。 當「訂閱者」的資料列在「發行者」端插入時，這會導致無法偵測的衝突發生。
資料行篩選無法篩選出不可為 Null 的 階層 ID 資料行。 從訂閱者的插入會失敗，因為發行者上沒有 hierarchyid 資料行的預設值。
只要篩選不包含 hierarchyid 資料行，就支援資料列篩選。