Normalizing HIERARCHYID Values

When using the HIERARCHYID datatype to represent graphs, in certain cases the values can become long. With very deep graphs this is natural, since the HIERARCHYID value represents a path of all nodes leading to the current starting with the root node. However, in certain cases even when the graph is not very deep, the path can become long. First I’ll explain the circumstances in which this can happen, and then I’ll provide a solution to normalizing the values, making them shorter.

HIERARCHYID values can become long when you keep adding new nodes in between two existing nodes that have consecutive values in the last numeric element in their canonical path. As an example, say you have two nodes with the following canonical paths: /1/ and /2/, and you add a node between them. You get a new value whose canonical path is /1.1/. Now add a value between /1.1/ and /2/ and you get /1.2/. Now add a value between /1.1/ and /1.2/ and you get /1.1.1/. As you can realize, if you keep adding nodes in between two existing nodes in this manner, you can get lengthy paths that represent lengthy HIERARCHYID values even when the graph is not deep.

If order among siblings is not important, you can add child nodes always after the last child, or always before the first, and this way, the paths will be more economic. But when order among siblings matters, you can’t control this. If you frequently add new nodes between existing ones you may end up with very long HIERARCHYID values. In such a case, you can periodically run a procedure that I will provide here that normalizes the HIERARCHYID values for the whole graph, making them shorter.

Uses the following code to create a table called Employees and populate it with sample data:

USE tempdb;

CREATETABLE dbo.Employees

(

empidINT NOT NULL,

hidHIERARCHYID NOT NULL,

lvl AS hid.GetLevel() PERSISTED,

empname VARCHAR(25) NOT NULL

);

CREATEUNIQUE CLUSTERED INDEX idx_depth_first ON dbo.Employees(hid);

CREATEUNIQUE INDEX idx_breadth_first ON dbo.Employees(lvl, hid);

CREATEUNIQUE INDEX idx_empid ON dbo.Employees(empid);

GO

CREATEPROC dbo.AddEmp

@empidAS INT,

@mgridAS INT,

@leftempidAS INT,

@rightempid AS INT,

@empnameAS VARCHAR(25)

AS

DECLARE @hid AS HIERARCHYID;

IF @mgrid IS NULL

SET @hid = HIERARCHYID::GetRoot();

ELSE

SET @hid =(SELECT hid FROM dbo.Employees WHERE empid = @mgrid).GetDescendant

Then run the following code to show the current HIERARCHYID values and their canonical paths:

SELECT

empid,

REPLICATE(' | ', lvl) + empname AS emp,

hid,

hid.ToString() AS path

FROM dbo.Employees

ORDERBY hid;

You get the following output:

empid emp hidpath

------ -------- ----------------- -----------------------

1 A 0x/

2| B 0x58/1/

4| D 0x62C0/1.1/

6| F 0x6316/1.1.1/

8| H 0x6318B0/1.1.1.1/

9|| I 0x6318B580/1.1.1.1/1/

11|| K 0x6318B62C/1.1.1.1/1.1/

13|| L 0x6318B63160/1.1.1.1/1.1.1/

15|| N 0x6318B6318B/1.1.1.1/1.1.1.1/

17|| P 0x6318B6318C58/1.1.1.1/1.1.1.1.1/

19|| E 0x6318B6318C62C0/1.1.1.1/1.1.1.1.1.1/

21|| T 0x6318B6318C6316/1.1.1.1/1.1.1.1.1.1.1/

20|| S 0x6318B6318C6340/1.1.1.1/1.1.1.1.1.2/

18|| Q 0x6318B6318C68/1.1.1.1/1.1.1.1.2/

16|| O 0x6318B6318D/1.1.1.1/1.1.1.2/

…

As you can see, even though the tree is only three levels deep, some of the HIERARCHYID values became quite long due to the insertion order of siblings.

The solution that normalizes the values involves the following steps:

·Define a CTE called EmpsRN that calculates for each node a row number partitioned by parent ordered by current hid value.

·Define a recursive CTE called EmpsPath that iterates through the levels of the tree, starting with the root node, and proceeding to the next level of children in each iteration. Use this CTE to construct a new canonical path for the nodes. The root should be assigned with ‘/’, and for each node in the next level concatenate the parent’s path, the current node’s row number that represents its position under the parent, and a ‘/’.

·Join the Employees table with the EmpsPath CTE, and overwrite the existing hid values with the new ones that are converted from the new canonical paths.

Here’s the code that performs this normalization process:

WITH EmpsRN AS

(

SELECT

empid,

hid,

ROW_NUMBER() OVER(PARTITION BY hid.GetAncestor(1) ORDER BY hid) AS rownum

Discuss this Article 2

meganbearly (not verified)

on Feb 19, 2009

Thanks for your question Balaji!
I passed your question on to Itzik Ben-Gan. You can read his response below:
"Hi Balaji,
One thing that comes to mind that can help is to produce values with gaps when normalizing. That is, instead of using consecutive row numbers, multiply the row numbers by some factor.
This would allow producing values in between existing ones, so it would mitigate the problem in between normalization processes.
Cheers,
Itzik"
Megan Keller
Associate Editor, SQL Server Magazine
mkeller@sqlmag.com

An Eye opener in optimizing hierarchyid usage!
But, isn't it going suffer the flexibility of inserting members inbetween e.g., EXEC dbo.AddEmp @empid = 22, @mgrid = 8, @leftempid = 19, @rightempid = 21, @empname = 'X';
would add the following which doesn't disturb any other path below it
empid emp hid path
22 | | X 0x866580 /4/6.1/
But if it were to follow the structure post normalization all other rows needs to be updated. Is there any remedy to this?
Thanks
Balaji

From the Blogs

My initial goal in writing this series of posts was to outline some of the concerns surrounding Availability Groups (AGs) and SQL Server Agent Jobs – and call out how there is virtually no guidance from Microsoft on this front and then detail some of the pitfalls and options available for tackling this problem domain. I initially expected this series of posts to have between 25 and 30 posts – according to some of the early outlines I created ‘way back when’....More

Throughout this series of posts I’ve taken a somewhat pessimistic view of how SQL Server Agent jobs are managed within most organizations – meaning that most of the code and examples I’ve provided up until this point were based on assumptions about how CHANGE to jobs is managed. That pessimism, to date, has come in two forms:...More

In this series of posts I’ve called out some of the concerns related to SQL Server AlwaysOn Availability Groups and their interaction with SQL Server Agent jobs – both in the form of Batch Jobs (see post #3) and backups....More