Quick reminder: these operators need values that SQL Server can compare to detect duplicates and matches. If a data type is non-comparable, generic set-based scripts break immediately unless you cast. Most common troublemakers are legacy LOB types (text, ntext, image), and also xml in many compare/sort scenarios. And the new json since SQL Server 2025. So this is not only about one edge case, it is a design concern for reusable SQL tooling.

This is the simple repro:

DROP TABLE IF EXISTS [dbo].[TableA]
DROP TABLE IF EXISTS [dbo].[TableB]

CREATE TABLE [dbo].[TableA] (
    [JSON_Data] JSON
)

CREATE TABLE [dbo].[TableB] (
    [JSON_Data] JSON
)

SELECT * FROM [dbo].[TableA]
UNION
SELECT * FROM [dbo].[TableB]
GO

It fails with this SQL Server error:

Msg 5335, Level 16, State 1, Line 14
The data type json cannot be used as an operand to the UNION, INTERSECT or EXCEPT operators because it is not comparable.

That means generic scripts now need special handling whenever any source column is JSON.

Current practical fix is explicit cast:

SELECT CAST([JSON_Data] AS NVARCHAR(MAX)) FROM [dbo].[TableA]
UNION
SELECT CAST([JSON_Data] AS NVARCHAR(MAX)) FROM [dbo].[TableB]
GO

This works, but it also means more branching and more complexity in reusable SQL utilities. In practice, any metadata-driven script should detect non-comparable source types and auto-cast them to a comparable string/binary representation before applying set operators.

Note: Microsoft already added one json data type column in a new system view sys.external_models in SQL Server 2025. Check this query:

SELECT [o].[name], [c].[name], [tp].[name]
FROM [sys].[system_objects] [o]
	INNER JOIN [sys].[system_columns] [c] ON [c].[object_id] = [o].[object_id]
	INNER JOIN [sys]. [tp] ON [tp].[system_type_id] = [c].[system_type_id] AND [tp].[user_type_id] = [c].[user_type_id]
WHERE [tp].[name] = 'json'

I tested it with a very small demo below. The query searching for Id = 4 returns no row, because the table has only 1,2,3. After that, SELECT leaves @Id as 10, while SET changes it to NULL.

DROP TABLE IF EXISTS #tmp
CREATE TABLE #tmp
(
    Id INT NOT NULL PRIMARY KEY
)

INSERT INTO #tmp (Id)
SELECT *
FROM (VALUES (1), (2), (3)) a(n)

DECLARE @Id INT

SET @Id = 10

-- SELECT
SELECT @Id = Id FROM #tmp WHERE Id = 4

SELECT @Id AS [SELECT]

-- SET
SET @Id = (SELECT Id FROM #tmp WHERE Id = 4)

SELECT @Id AS [SET]

Result in this test: SELECT gives 10, SET gives NULL. So if “not found” should keep the old value, SELECT assignment can be useful. If “not found” should explicitly reset the variable, SET it gives you that behavior directly.

This is not something you will usually use in real production logic, but it is a useful edge case to know. It helps when you test how SQL Server validates object definitions and execution flow.

Simple demo:

CREATE PROCEDURE MyEmptyProcedure AS
GO

EXEC MyEmptyProcedure
GO

So yes, it really works. The procedure body can be empty, and SQL Server still allows create + execute.

With SQL Server 2025, Microsoft added a small but very practical improvement: the length parameter is now optional. If you omit it, SQL Server returns the substring from the start position to the end of the string.

See official doc: SUBSTRING (Transact-SQL) – optional length argument.

Syntax comparison

SQL Server 2022 (and earlier)

Length is required:

SUBSTRING(expression, start, length)

SQL Server 2025

Length can be omitted:

SUBSTRING(expression, start[, length])

Practical T-SQL: 2022 vs 2025

Example 1: Extract everything after a prefix

Let’s say you have a standard prefix and you want everything after it.

SQL Server 2022

DECLARE @s varchar(100) = 'ENV:prod-west-eu'; 

-- Get everything after 'ENV:'
SELECT SUBSTRING(@s, 5, LEN(@s) - 4) AS tail_2022;

SQL Server 2025

DECLARE @s varchar(100) = 'ENV:prod-west-eu'; 

-- Get everything after 'ENV:' (length omitted) 
SELECT SUBSTRING(@s, 5) AS tail_2025;

Example 2: Split at a delimiter (common pattern)

Extract everything after the first colon (:).

SQL Server 2022

DECLARE @s varchar(100) = 'ServerName:SQL2022-01'; 

SELECT SUBSTRING(@s, CHARINDEX(':', @s) + 1, LEN(@s)) AS after_colon_2022;

SQL Server 2025

DECLARE @s varchar(100) = 'ServerName:SQL2025-01'; 

SELECT SUBSTRING(@s, CHARINDEX(':', @s) + 1) AS after_colon_2025;

One important detail: omitted vs NULL length

The new behavior is triggered only when the third parameter is omitted. If you explicitly pass NULL as length, the result is still NULL (same as older versions).

-- Same behavior (2022 and 2025): returns NULL because length is explicitly NULL
SELECT SUBSTRING('abc123', 4, NULL) AS returns_null;

Conclusion

This change is small, but in daily T-SQL work it’s one of those “finally!” improvements. Anywhere you currently compute remaining length or use overshoot constants, SQL Server 2025 lets you write cleaner and more intention-revealing code.

If you’re maintaining scripts that must run on both SQL Server 2022 and 2025, keep the old 3-argument form for compatibility.

CREATE OR ALTER VIEW dbo.SampleView
AS
	SELECT	* FROM sys.tables

	this_is_hidden_text_in_the_view

GO

In the medata you will see:

SELECT * FROM sys.[sql_modules] WHERE [definition] LIKE '%hidden_tex%'

Storing free text that isn’t a valid T-SQL statement within a view definition can indeed break code consistency rules and potentially lead to confusions in database management and development. Here are several key points to explain this concern:

1. Code Consistency: Views in SQL Server are designed to encapsulate logical queries that retrieve and present data in a structured manner. They should adhere to standard SQL syntax and maintain a clear purpose. Introducing free text that isn’t part of a valid SQL statement contradicts this principle of consistency. It blurs the line between executable code and documentation, potentially making it harder for developers to understand and maintain the view over time.
2. Parsing and Execution: SQL Server parses and executes the view definition to retrieve data when the view is queried. Any non-SQL text included in the view definition, such as comments or free text, is ignored during this process. While this doesn’t affect the functionality of the view directly, it can mislead developers who might expect the free text to behave as part of the SQL logic.
3. Maintenance Challenges: Over time, as views are updated or modified, the non-SQL text within their definitions may become outdated or irrelevant. This can confuse developers who rely on accurate documentation embedded within the code. It also creates maintenance challenges, as developers might overlook or misinterpret the purpose of the non-SQL text during updates.
4. Communication and Collaboration: In collaborative environments, adhering to consistent coding practices ensures that all team members can easily understand and work with database objects. Non-standard practices like embedding free text in view definitions can hinder effective communication about the view’s purpose, leading to misunderstandings or errors in development and maintenance tasks.
5. Documentation Separation: Best practices advocate for separating documentation from executable code. While comments within SQL code (using /* */ or --) are valid and beneficial for documenting SQL logic, embedding free text directly within view definitions blurs this distinction. It introduces content that isn’t intended for execution but might be mistakenly interpreted as such.
6. Risk of Misinterpretation: Developers unfamiliar with the database might misinterpret non-SQL text within view definitions as part of the SQL logic. This misunderstanding can lead to incorrect assumptions about the functionality or design intent of the view, potentially causing errors or inefficiencies in application development.

Conclusion

In conclusion, while adding non-SQL free text to view definitions might seem convenient for documentation purposes, it poses risks to code consistency and clarity in SQL Server development. It’s advisable to adhere to established coding standards and separate documentation from executable code to maintain transparency, facilitate maintenance, and mitigate confusion among developers working with database objects. Clear communication and consistent practices are key to ensuring the reliability and manageability of database systems over time.

Numbered stored procedures allow you to create a series of procedures that share the same base name, but each is distinguished by a unique integer. For example, you can have procedures named MyProc;1, MyProc;2, and so on. This can be useful for organizing related procedures or implementing certain types of versioning.

Syntax and Usage

The basic syntax for creating numbered stored procedures is:

CREATE PROCEDURE procedure_name;number
AS
BEGIN
    -- SQL statements
END

To execute a numbered stored procedure, you use the following syntax:

EXEC procedure_name;number

Example

Let’s create a series of numbered stored procedures that demonstrate a simple use case.

Create the first procedure in the series:

CREATE PROCEDURE MyProc;1
AS
BEGIN
    SELECT 'This is procedure 1' AS Message;
END

Create the second procedure in the series:

CREATE PROCEDURE MyProc;2
AS
BEGIN
    SELECT 'This is procedure 2' AS Message;
END

Create the third procedure in the series:

CREATE PROCEDURE MyProc;3
AS
BEGIN
    SELECT 'This is procedure 3' AS Message;
END

Executing Numbered Stored Procedures

To execute these procedures, use the following commands:

EXEC MyProc;1
EXEC MyProc;2
EXEC MyProc;3

Each execution will return the message defined in the respective procedure.

Managing Numbered Stored Procedures

To drop a specific numbered stored procedure, use the following syntax:

DROP PROCEDURE procedure_name;number

For example, to drop MyProc;2, you would use:

DROP PROCEDURE MyProc;2

Advantages and Disadvantages

Advantages:

• Organization: Numbered stored procedures can help organize related procedures under a common base name.
• Versioning: They can be used to manage different versions of a procedure without renaming the base procedure.

Disadvantages:

• Complexity: Numbered stored procedures can add complexity to database management and maintenance.
• Obsolescence: This feature is not widely used or supported in modern SQL Server practices, making it less familiar to many developers and DBAs.

Conclusion

While numbered stored procedures offer a way to organize and manage related SQL procedures, they are not commonly used in contemporary SQL Server development. Understanding this feature can be useful for legacy systems or specific scenarios where such organization is beneficial. However, for most purposes, it is recommended to use more modern techniques for managing stored procedures, such as naming conventions and version control systems.

@@IDENTITY

• returns data type numeric (38,0)
• after completing INSERT, SELECT INTO, or BULKCOPY, returns the last identity column value in the table
• if there is no identity column in the table, returns NULL
• if multiple rows are inserted and multiple identity values are generated, the last value is returned
• if a trigger is fired that increases the identity value, @@IDENTITY returns this trigger-increased value
• @@IDENTITY does not revert to the previous value if a rollback or insert failure occurs – for example, if a failure occurs on IGNORE_DUP_KEY, the identity for the given table is still incremented
• @@IDENTITY, SCOPE_IDENTITY, and IDENT_CURRENT are similar functions, all returning the last inserted identity column value in the table
• @@IDENTITY and SCOPE_IDENTITY return the last generated identity value in any table of the current session. SCOPE_IDENTITY returns the value only within the scope, @@IDENTITY regardless of the scope.
• IDENT_CURRENT is not limited by session or scope but only by the specific table, for which it independently returns the last identity
• @@IDENTITY applies only to the current session on the local server. It cannot be called for a linked or remote server => it is necessary to create a stored procedure on the remote server, use @@IDENTITY in it, and call it in the context of the remote server
• it is not suitable for use in replications – replication triggers can affect the identity value because the identity of the last row of the table is not returned, but the identity of the row inserted by the trigger into replication tables => existing procedures must be rewritten to SCOPE_IDENTITY()

SCOPE_IDENTITY()

• returns the last identity value within the scope => scope is defined as a module: stored procedure, trigger, function, or batch
• returns numeric
• difference between @@IDENTITY and SCOPE_IDENTITY: (BOL example)
  • For example, there are two tables, T1 and T2, and an INSERT trigger is defined on T1. When a row is inserted to T1, the trigger fires and inserts a row in T2. This scenario illustrates two scopes: the insert on T1, and the insert on T2 by the trigger.
  • Assuming that both T1 and T2 have identity columns, @@IDENTITY and SCOPE_IDENTITY will return different values at the end of an INSERT statement on T1. @@IDENTITY will return the last identity column value inserted across any scope in the current session. This is the value inserted in T2. SCOPE_IDENTITY() will return the IDENTITY value inserted in T1. This was the last insert that occurred in the same scope. The SCOPE_IDENTITY() function will return the null value if the function is invoked before any INSERT statements into an identity column occur in the scope.

IDENT_CURRENT()

• returns the identity of the last operation for a specific table regardless of session and scope
• usage: IDENT_CURRENT( ‘table_name’ )
• returns numeric(38,0)
• if the caller does not have permissions on the table, returns NULL or an error
• if the table does not exist, returns NULL
• if the table is empty, returns the first identity seed
• beware of the difference when deleting using DELETE (does not reset identity) and TRUNCATE (resets identity)
• rolling back a transaction or an error never returns the identity value => the number remains incremented as if the transaction was committed

IDENT_INCR()

• returns the increment size (e.g., 1)
• usage: IDENT_INCR ( ‘table_or_view’ )

IDENT_SEED()

• returns the initial value from which the increment starts
• usage: IDENT_SEED ( ‘table_or_view’ )

DBCC CHECKIDENT

• returns the initial value from which the increment starts
• usage:
  • DBCC CHECKIDENT ( table_name [ , { NORESEED | { RESEED [ , new_reseed_value ] } } ] )
    [ WITH NO_INFOMSGS ]
• checks the current identity value in a specific table and possibly changes it – allows setting a new next identity value for the table
• the table must contain an identity column
• this cannot change the initial seed value when creating the column or reseeding existing data => for this, the identity column must be recreated
• example: DBCC CHECKIDENT (“HumanResources.Employee”, RESEED, 30);

Method 1: Using BINARY Casting

One way to generate an empty GUID in SQL Server is by first casting the integer 0 to a binary value, and then casting that binary value to a UNIQUEIDENTIFIER. Here’s how it’s done:

SELECT CAST(CAST(0 AS BINARY) AS UNIQUEIDENTIFIER) AS EmptyGUID;

In this method, the integer 0 is first converted into a binary representation. Since the binary representation does not fill the entire 16 bytes required by a GUID, SQL Server automatically pads the remaining bytes with zeros.The final cast to UNIQUEIDENTIFIER results in an empty GUID.

Method 2: Using Hexadecimal Representation

Another approach to generate an empty GUID is by directly casting a hexadecimal value that represents zero to a UNIQUEIDENTIFIER. This method is more concise and looks like this:

SELECT CAST(0x0 AS UNIQUEIDENTIFIER) AS EmptyGUID;

Here, 0x0 represents a hexadecimal constant for zero. When this is cast to a UNIQUEIDENTIFIER, SQL Server interprets this as an instruction to generate a GUID consisting entirely of zeros, resulting in an empty GUID.

Method 3: Using the NEWID() Function with Replacement

Although not as straightforward or efficient for simply generating an empty GUID, you could technically use the NEWID() function to generate a new GUID and then replace it with an empty GUID using string manipulation functions. This method is more of a curiosity and is not recommended for practical use due to its unnecessary complexity and performance implications:

SELECT REPLACE(CAST(NEWID() AS VARCHAR(36)), CAST(NEWID() AS VARCHAR(36)), '00000000-0000-0000-0000-000000000000')

This essentially generates a new GUID and then replaces it with the string representation of an empty GUID. Again, this is not a practical approach but is mentioned here for completeness.

Method 4: Direct Assignment in Variables or Table Defaults

Another straightforward method, especially when working with variables or setting default values for table columns, is to directly assign the empty GUID value:

Variables:

DECLARE @EmptyGUID UNIQUEIDENTIFIER = '00000000-0000-0000-0000-000000000000'

Table Defaults:

CREATE TABLE MyTable (
    ID UNIQUEIDENTIFIER DEFAULT '00000000-0000-0000-0000-000000000000' NOT NULL,
    Name NVARCHAR(50)
);

Conclusion

While the direct casting from a zero binary or hexadecimal value represents the most straightforward and efficient method to generate an empty GUID in SQL Server, understanding the various ways to accomplish this task provides flexibility for SQL developers. The method of choice might depend on the specific scenario, such as initializing variables, setting default values in table definitions, or more complex logic that might, for some reason, necessitate a different approach.

Setting Up the dbo.Employee Table

First, we’ll create the dbo.Employee table and populate it with sample data. This setup will serve as the foundation for our examples.

-- Creation of dbo.Employee table
CREATE TABLE dbo.Employee (
    EmployeeID INT PRIMARY KEY,
    FirstName NVARCHAR(50),
    LastName NVARCHAR(50),
    Position NVARCHAR(50),
    Department NVARCHAR(50),
    Salary INT
);

-- Inserting sample data into dbo.Employee
INSERT INTO dbo.Employee (EmployeeID, FirstName, LastName, Position, Department, Salary)
VALUES
    (1, 'John', 'Doe', 'Software Engineer', 'Engineering', 70000),
    (2, 'Jane', 'Smith', 'Project Manager', 'Project Management', 85000),
    (3, 'William', 'Johnson', 'Data Analyst', 'Data Science', 75000),
    (4, 'Emma', 'Brown', 'UI/UX Designer', 'Design', 68000),
    (5, 'Michael', 'Davis', 'DevOps Engineer', 'Engineering', 90000);

With our table ready, let’s explore how to use the JSON_OBJECT() function with the dbo.Employee table through a series of examples.

Example 1: Creating a Simple JSON Object

In this first example, we create a JSON object for each employee that includes their ID, full name, and position.

SQL Query:

SELECT 
    JSON_OBJECT(
        'EmployeeID':CAST(EmployeeID AS NVARCHAR(10)),
        'FullName':CONCAT(FirstName, ' ', LastName),
        'Position':Position
    ) AS EmployeeJSON
FROM dbo.Employee;

JSON Output:

{"EmployeeID":"1","FullName":"John Doe","Position":"Software Engineer"}
{"EmployeeID":"2","FullName":"Jane Smith","Position":"Project Manager"}
{"EmployeeID":"3","FullName":"William Johnson","Position":"Data Analyst"}
{"EmployeeID":"4","FullName":"Emma Brown","Position":"UI\/UX Designer"}
{"EmployeeID":"5","FullName":"Michael Davis","Position":"DevOps Engineer"}

Example 2: Nesting JSON Objects

We explore the creation of nested JSON objects. Here, we structure the JSON to include a nested object for the department, showcasing a more complex data hierarchy.

SQL Query:

SELECT 
    JSON_OBJECT(
        'EmployeeID': CAST(EmployeeID AS NVARCHAR(10)),
        'FullName': CONCAT(FirstName, ' ', LastName),
        'Position': Position,
        'Department': JSON_OBJECT('Name': Department, 'BudgetCode': 'XYZ123')
    ) AS EmployeeJSON
FROM dbo.Employee;

JSON Output:

For an employee in the Engineering department, the JSON output would appear as follows:

{
    "EmployeeID": "1",
    "FullName": "John Doe",
    "Position": "Software Engineer",
    "Department": {
        "Name": "Engineering",
        "BudgetCode": "XYZ123"
    }
}

Through these examples, it’s clear how the JSON_OBJECT() function can be utilized to produce structured JSON data directly from SQL queries, simplifying the integration between SQL Server and applications that operate with JSON. Whether you’re creating simple or complex JSON objects, JSON_OBJECT() offers the flexibility and power to meet your data serialization needs.

[toc]

Preparing data

Let’s create some sample data first. Nothing complicated: simple list of employees and their managers like it’s common in the organization hierarchy. It has two parent nodes (AMY and LAURA) and up to five child levels. I kept it simple for demonstration purposes and each employee’s name is unique and every employee has only one manager. Most of the options will work for multiple parents (navigation) paths too but it may require some changes. I will post on the multiple-parent hierarchy later.

CREATE TABLE [#Source] (
	[Employee_Id] INT NOT NULL PRIMARY KEY,
	[Name] NVARCHAR(100) NOT NULL,
	[Manager] NVARCHAR(100) NULL
)

;WITH [c] ( [Employee_Id], [Name], [Manager] ) AS
(
	SELECT 1,  'AMY',	NULL        UNION ALL
	SELECT 2,  'DANIEL',	'AMY'       UNION ALL
	SELECT 3,  'EMILY',	'AMY'       UNION ALL
	SELECT 4,  'HANNAH',	'AMY'       UNION ALL
	SELECT 5,  'JACK',	'HANNAH'    UNION ALL
	SELECT 6,  'JAMES',	'HANNAH'    UNION ALL
	SELECT 7,  'JESSICA',	'JAMES'     UNION ALL
	SELECT 8,  'JOSHUA',	'JAMES'     UNION ALL
	SELECT 9,  'LAURA',	NULL        UNION ALL
	SELECT 10, 'LUKE',	'LAURA'     UNION ALL
	SELECT 11, 'MATTHEW',	'LAURA'     UNION ALL
	SELECT 12, 'OLIVIA',	'MATTHEW'   UNION ALL
	SELECT 13, 'REBECCA',	'MATTHEW'   UNION ALL
	SELECT 14, 'RYAN',	'REBECCA'   UNION ALL
	SELECT 15, 'SOPHIE',	'RYAN'	    UNION ALL
	SELECT 16, 'THOMAS',	'SOPHIE'
) 
INSERT INTO [#Source]
   ( [Employee_Id], [Name], [Manager] )
   SELECT [c].[Employee_Id], [c].[Name], [c].[Manager]
   FROM [c]

SELECT * FROM [#Source]
GO

The script above will create [#Source] temporary table with the following data:

Please note that AMY and LAURA have Manager fields empty. They are our super bosses, two top-level nodes where the hierarchy path tree is starting.

We will a little bit transform this basic dataset user recursive CTE and save it as an optimized dataset into the [#Data] table.

CREATE TABLE [#Data] (
	[Employee_Id] INT NOT NULL PRIMARY KEY,
	[Name] NVARCHAR(100) NOT NULL,
	[Manager] NVARCHAR(100) NULL,
	[Manager_Id] INT NULL,
	[Level] INT NOT NULL,
	[Path] NVARCHAR(MAX) NOT NULL
)

;WITH [c] AS 
(
	SELECT [Employee_Id], [Name], [Manager], CAST(NULL AS INT) [Manager_Id], 1 [Level], CAST([Name] AS NVARCHAR(MAX)) AS [Path]
	FROM [#Source]
	WHERE [Manager] IS NULL

	UNION ALL
	
	SELECT [d].[Employee_Id], [d].[Name], [d].[Manager], [c].[Employee_Id], [c].[Level] + 1, [c].[Path] + '->' + [d].[Name]
	FROM [#Source] [d]
		INNER JOIN [c] ON [c].[Name] = [d].[Manager]
)
INSERT INTO [#Data]
	(	[Employee_Id], [Name], [Manager], [Manager_Id], [Level], [Path] )
	SELECT [Employee_Id], [Name], [Manager], [Manager_Id], [Level], [Path]
	FROM [c]

SELECT * FROM [#Data]
GO

We can see the source hierarchy presented visually now and we will save some data processing later.

Adjacency list (Parent/Child)

This is probably the most used option to persist hierarchical data in SQL Server (and other RDBMS). It persists the reference to the parent node in every child node.

CREATE TABLE [dbo].[Employees_Adjacency]
(
   [Employee_Id] INT NOT NULL PRIMARY KEY,
   [Name] NVARCHAR(100) NOT NULL,
   [Parent_Employee_Id] INT NULL,
   CONSTRAINT [FK_Employees_Adjacency] 
      FOREIGN KEY ( [Parent_Employee_Id]) REFERENCES [dbo].[Employees_Adjacency] ([Employee_Id])
)
GO

INSERT INTO [dbo].[Employees_Adjacency]
(   [Employee_Id], [Name], [Parent_Employee_Id] )
   SELECT [Employee_Id], [Name], [Manager_Id]
   FROM [#Data]
GO

SELECT * FROM [dbo].[Employees_Adjacency]
GO

We have created [dbo].[Employees_Adjacency] with the self-referencing [Parent_Employee_Id] column (note the highlighted FK constraint) and populated it with data from [#Data] table:

It’s very similar to the original [#Source] except that Manager of every employee is expressed in the [Parent_Employee_Id] as a reference to the [Employee_Id] unique employee Id (Primary Key).

We can revert the process now and check if the parent-child hierarchy is correct using recursive CTE:

;WITH [c] AS 
(
	SELECT [Employee_Id], [Name], [Parent_Employee_Id], CAST(NULL AS NVARCHAR(100)) [Parent_Employee_Name], 1 [Level], CAST([Name] AS NVARCHAR(MAX)) AS [Path]
	FROM [dbo].[Employees_Adjacency]
	WHERE [Parent_Employee_Id] IS NULL

	UNION ALL
	
	SELECT 
		[d].[Employee_Id], [d].[Name], [d].[Parent_Employee_Id], [d].[Name], [c].[Level] + 1, [c].[Path] + '->' + [d].[Name]
	FROM [dbo].[Employees_Adjacency] [d]
		INNER JOIN [c] ON [c].[Employee_Id] = [d].[Parent_Employee_Id]
)
SELECT [c].[Employee_Id], [c].[Name], [c].[Parent_Employee_Id], [c].[Parent_Employee_Name], [c].[Level], [c].[Path]
FROM [c]

It perfectly matches our original source.

Closure table

This is similar to an adjacency list. The only main difference is that the parent-child relationship is stored separately from the data itself.

This can be done in two ways: We will simply move the hierarchy to a different table as it is or we will transform it a little bit and switch the key and parent-key column.

Simple movement of the hierarchy to a dedicated table

CREATE TABLE [dbo].[Employees]
(
	[Employee_Id] INT NOT NULL PRIMARY KEY,
	[Name] NVARCHAR(100) NOT NULL
)
GO

INSERT INTO [dbo].[Employees]
(	[Employee_Id], [Name] )
	SELECT 
		[Employee_Id], [Name]
	FROM [#Data]
GO

SELECT * FROM [dbo].[Employees]
GO

We have created [dbo].[Employees] table and filled just employee ids and names. There is nothing about the hierarchy.

We need to create a dedicated table [dbo].[Employees_Hierarchy_1] to save all the hierarchical relations between individual employees now. Please note that the [Employee_Id] is the only participant in the unique primary key constraint.

CREATE TABLE [dbo].[Employees_Hierarchy_1]
(
	[Employee_Id] INT NOT NULL PRIMARY KEY,
	[Parent_Employee_Id] INT NULL,
	CONSTRAINT [FK_Employees_Hierarchy_1_Employees_Employee_Id] FOREIGN KEY ( [Employee_Id]) REFERENCES [dbo].[Employees] ([Employee_Id]),
	CONSTRAINT [FK_Employees_Hierarchy_1_Employees_Parent_Employee_Id] FOREIGN KEY ( [Parent_Employee_Id]) REFERENCES [dbo].[Employees] ([Employee_Id]),
	CONSTRAINT [FK_Employees_Hierarchy_1] FOREIGN KEY ( [Parent_Employee_Id]) REFERENCES [dbo].[Employees_Hierarchy_1] ([Employee_Id])
)
GO

INSERT INTO [dbo].[Employees_Hierarchy_1]
( [Employee_Id], [Parent_Employee_Id] )
   SELECT [Employee_Id], [Manager_Id]
   FROM [#Data]
GO

SELECT * FROM [dbo].[Employees_Hierarchy_1]
GO

We can bind it back together using two joins between the main data table and hierarchy table:

SELECT 
	e.[Employee_Id], e.[Name], pe.[Employee_Id], pe.[Name]
FROM [dbo].[Employees_Hierarchy_1] [eh1]
	INNER JOIN [dbo].[Employees] [e] ON [e].[Employee_Id] = [eh1].[Employee_Id]
	LEFT JOIN [dbo].[Employees] pe ON pe.[Employee_Id] = [eh1].[Parent_Employee_Id]
GO

We will verify it using the recursive CTE again:

;WITH [c] AS 
(
	SELECT e.[Employee_Id], e.[Name], eh1.[Parent_Employee_Id], CAST(NULL AS NVARCHAR(100)) [Parent_Employee_Name], 1 [Level], CAST([Name] AS NVARCHAR(MAX)) AS [Path]
	FROM [dbo].[Employees_Hierarchy_1] eh1
		INNER JOIN dbo.[Employees] e ON [e].[Employee_Id] = [eh1].[Employee_Id]
	WHERE eh1.[Parent_Employee_Id] IS NULL

	UNION ALL
	
	SELECT 
		[e].[Employee_Id], [e].[Name], [eh1].[Parent_Employee_Id], [e].[Name], [c].[Level] + 1, [c].[Path] + '->' + [e].[Name]
	FROM [dbo].[Employees_Hierarchy_1] eh1
		INNER JOIN [c] ON [c].[Employee_Id] = [eh1].[Parent_Employee_Id]
		INNER JOIN [dbo].[Employees] e ON [e].[Employee_Id] = [eh1].[Employee_Id]
)
SELECT [c].[Employee_Id], [c].[Name], [c].[Parent_Employee_Id], [c].[Parent_Employee_Name], [c].[Level], [c].[Path]
FROM [c]
ORDER BY 1
GO

This solution may look as it’s more complicated, with more tables and joins at first look. That’s right. But it may have various advantages if we will think about it from the data modification point of view. We can edit employees separately from their hierarchy. We can optimize the hierarchy for searching, nodes movements, etc. much easier in a dedicated table. I will come back to it in a related post.

Moving the hierarchy to a real closure table (parent/node columns switch)

The second option how to move the hierarchy to a separated table is very similar to the first one. The main difference is that the [Parent_Employee_Id] is moved to be the first column in the table and it’s forming a unique primary key with the [Employee_Id] column.

CREATE TABLE [dbo].[Employees_Hierarchy_2]
(
	[Parent_Employee_Id] INT NOT NULL,
	[Employee_Id] INT NOT NULL,
	[Depth] INT NOT NULL,
	CONSTRAINT [PK_Employees_Hierarchy_2] PRIMARY KEY CLUSTERED ([Parent_Employee_Id], [Employee_Id]),
	CONSTRAINT [FK_Employees_Hierarchy_2_Employees_Parent_Employee_Id] FOREIGN KEY ( [Parent_Employee_Id]) REFERENCES [dbo].[Employees] ([Employee_Id]),
	CONSTRAINT [FK_Employees_Hierarchy_2_Employees_Employee_Id] FOREIGN KEY ( [Employee_Id]) REFERENCES [dbo].[Employees] ([Employee_Id])
)
GO

We need to adjust the data load process. We can’t import the data as is because the two top-level nodes (AMY and LAURE) haven’t a manager assigned (NULL  value). This will lead to an error when we will try to insert NULL or duplicated value to the unique primary key. To override it we will generate self-referencing parents for top-level nodes. Same time we will generate a self-referencing node for every employee.

;WITH [c] AS
(
	
	SELECT  [d].[Employee_Id] [Manager_Id], [d].[Employee_Id], 0 AS [Depth], CAST([d].[Name] AS NVARCHAR(MAX)) [Name]
	FROM [#Data] [d]

	UNION ALL

	SELECT [c].[Manager_Id], [d].[Employee_Id], [c].[Depth] + 1, [c].[Name] + '->' + [d].[Name]
	FROM [#Data] [d]
		INNER JOIN [c] ON [d].[Manager_Id] = [c].[Employee_Id]
)
INSERT INTO [dbo].[Employees_Hierarchy_2]
	(	[Parent_Employee_Id], [Employee_Id], [Depth] )
	SELECT 
		[c].[Manager_Id], [c].[Employee_Id], [c].[Depth]
	FROM [c]
GO

SELECT * FROM [dbo].[Employees_Hierarchy_2]
GO

The new [Depth] column is one of the biggest benefits the closure table approach is bringing to us. In combination with self-referencing nodes it allows us very effectively search for all nodes at a given dept-level in a hierarchy:

SELECT [h].[Parent_Employee_Id], [pe].[Name], [e].[Employee_Id], [e].[Name]
FROM [dbo].[Employees_Hierarchy_2] [h]
	INNER JOIN [dbo].[Employees] [e] ON [e].[Employee_Id] = [h].[Employee_Id]
	INNER JOIN [dbo].[Employees] [pe] ON [pe].[Employee_Id] = [h].[Parent_Employee_Id]
WHERE [h].[Depth] = 3
GO

If you will check the data returned with the visual presentation of the hierarch above it’s pretty good visible that we have obtained all employees that are in the distance of 3 levels from their parents.

See more in related links below on how to mine as much as possible from the closure tables concept.

Nested Set

Nested Sets or the Nested Set Model is another technique how to store hierarchical data. It’s using the concept of left and right bowers to number nodes according to tree traversal navigation. I will recommend reading the Wiki for more information because this option isn’t as intuitive as the others. I have prepared the sample using an amazing CTE-based solution published by Jeff Moden. Read it for more details on how exactly the nested set’s generator works.

CREATE TABLE [#Tally] ([N] INT NOT NULL PRIMARY KEY)

;WITH [Tally] ([N]) AS
(
	SELECT ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
	FROM (VALUES(0),(0),(0),(0),(0),(0),(0),(0),(0),(0)) [a] ([n])
		CROSS JOIN (VALUES(0),(0),(0),(0),(0),(0),(0),(0),(0),(0)) [b] ([n])
		CROSS JOIN (VALUES(0),(0),(0),(0),(0),(0),(0),(0),(0),(0)) [c] ([n])
)
INSERT INTO [#Tally] ([N])
	SELECT * FROM [Tally]
GO

;WITH [c] AS 
( 
	SELECT [Employee_Id], [Manager_Id], 1 AS [Level], CAST(CAST([Employee_Id] AS BINARY(4)) AS VARBINARY(4000)) AS [Sort]
	FROM [#Data]
	WHERE [Manager_Id] IS NULL
	
	UNION ALL 
 
	SELECT [e].[Employee_Id], [e].[Manager_Id], [c].[Level] + 1, CAST([c].[Sort] + CAST([e].[Employee_Id] AS BINARY(4)) AS VARBINARY(4000))
	FROM [#Data] [e]
		INNER JOIN [c] ON [c].[Employee_Id] = [e].[Manager_Id]
)
SELECT
    ISNULL([Employee_Id], 0) [Employee_Id], [Manager_Id], ISNULL([Level], 0) [Level], 
    ISNULL(CAST(0 AS INT),0) [LeftBower], ISNULL(CAST(0 AS INT),0) [RightBower],
    ROW_NUMBER() OVER (ORDER BY [Sort]) [NodeNumber],
    ISNULL(CAST(0 AS INT),0) [NodeCount], ISNULL([Sort],[Sort]) [Sort]
   INTO [dbo].[Employees_NestedSets]
FROM [c] 
OPTION (MAXRECURSION 0)

DECLARE @LeftBower INT;

;WITH [c] AS
( 
	SELECT CAST(SUBSTRING([h].[Sort],[t].[N],4) AS INT) [Employee_Id], 
        COUNT(*) [NodeCount]
	FROM [dbo].[Employees_NestedSets] [h], [#Tally] [t]
	WHERE [t].[N] BETWEEN 1 AND DATALENGTH([h].[Sort])
	GROUP BY SUBSTRING([h].[Sort], [t].[N], 4)
) 
UPDATE [h]
	SET @LeftBower = [LeftBower] = 2 * [NodeNumber] - [Level],
        [h].[NodeCount]  = [c].[NodeCount],
        [h].[RightBower] = ([c].[NodeCount] - 1) * 2 + @LeftBower + 1
FROM [dbo].[Employees_NestedSets] [h]
	INNER JOIN [c] ON [h].[Employee_Id] = [c].[Employee_Id]

ALTER TABLE [dbo].[Employees_NestedSets] ADD CONSTRAINT [PK_Employees_NestedSets] PRIMARY KEY CLUSTERED ([LeftBower], [RightBower])
CREATE UNIQUE INDEX [UX_Employees_NestedSets] ON [dbo].[Employees_NestedSets] ([Employee_Id]) 
ALTER TABLE [dbo].[Employees_NestedSets] ADD CONSTRAINT [FK_Employees_NestedSets_Employees_NestedSets_Manager_Id] FOREIGN KEY ([Manager_Id]) REFERENCES [dbo].[Employees_NestedSets] ([Employee_Id]) 

SELECT * FROM [dbo].[Employees_NestedSets]
GO

We have created [#Tally] table with 1000 numbers to support quick processing for CTEs following. The final result set is generated into [dbo].[Employees_NestedSets] and this table is enriched with some constraints to enforce data consistency and support search performance.

Green marked columns are responsible for the magic. These are the left and right boundary values used for navigation in the hierarchy. I.e., we would like to get the full path for THOMAS. There is no need for recursive CTE like with parent/child or other options. We will perform a simple WHERE condition search using the BETWEEN operator and concatenate Employee names using STRING_AGG() function into the final path:

DECLARE @ThomasLB INT

SELECT @ThomasLB = [LeftBower] 
FROM [dbo].[Employees_NestedSets] [h]
	INNER JOIN [#Data] [e] ON [e].[Employee_Id] = [h].[Employee_Id]
WHERE [e].[Name] = 'THOMAS'

SELECT STRING_AGG([e].[Name], '=>') WITHIN GROUP (ORDER BY [h].[Level]) [Path]
FROM [dbo].[Employees_NestedSets] [h]
	INNER JOIN [#Data] [e] ON [e].[Employee_Id] = [h].[Employee_Id]
WHERE @ThomasLB BETWEEN [LeftBower] AND [RightBower]
GO

Amazing, right? But every solution has its own pros and cons so read the article carefully. For nested sets, the complexity is mainly at the level of data modifications when bowers should be recalculated.

XML

Storing hierarchical data in XML format is easy. XML is designed to be a set of nested nodes by its nature and it is natively supported in SQL Server.

We will build the hierarchical XML nodes tree using a recursive scalar function. Because temporary tables cannot be used in scalar functions we need to move data from the [#Data] table to the physical table [dbo].[Data]. Finally, FOR XML PATH will do the jobs and convert the dataset to an XML tree.

SELECT *
	INTO [dbo].[Data]
FROM [#Data]
GO

CREATE OR ALTER FUNCTION [SelectChild] (
	@key AS INT
)
RETURNS XML
BEGIN
    RETURN (
        SELECT 
            [Employee_Id] AS '@Id', [Name] AS '@Name',
            [dbo].[SelectChild]([Employee_Id])
        FROM [Data]
        WHERE [Manager_Id] = @key
        FOR XML PATH('Employee'), TYPE
    )
END
GO

SELECT 
    [Employee_Id] AS '@Id', [Name] AS '@Name',
    [dbo].[SelectChild]([Employee_Id])     
FROM [Data]
WHERE [Manager_Id] IS NULL
FOR XML PATH ('Employee'), ROOT('Employees')
GO

And the XML:

<Employees>
  <Employee Id="1" Name="AMY">
    <Employee Id="2" Name="DANIEL" />
    <Employee Id="3" Name="EMILY" />
    <Employee Id="4" Name="HANNAH">
      <Employee Id="5" Name="JACK" />
      <Employee Id="6" Name="JAMES">
        <Employee Id="7" Name="JESSICA" />
        <Employee Id="8" Name="JOSHUA" />
      </Employee>
    </Employee>
  </Employee>
  <Employee Id="9" Name="LAURA">
    <Employee Id="10" Name="LUKE" />
    <Employee Id="11" Name="MATTHEW">
      <Employee Id="12" Name="OLIVIA" />
      <Employee Id="13" Name="REBECCA">
        <Employee Id="14" Name="RYAN">
          <Employee Id="15" Name="SOPHIE">
            <Employee Id="16" Name="THOMAS" />
          </Employee>
        </Employee>
      </Employee>
    </Employee>
  </Employee>
</Employees>

To be honest: This is just a demonstration. It will have poor performance and huge complexity in case of large hierarchies and various data modifications like nodes movement. But it might be a really good format for a simple exchange of hierarchical data structure between SQL Server and different database platforms, API, or external data sources.

JSON

With the JSON is the situation exactly the same as with the XML. We will change the scalar function to work with JSON instead of XML using FOR JSON PATH clause. All the rest is similar.

CREATE OR ALTER FUNCTION [SelectChild_JSON] (
	@key AS INT
)
RETURNS NVARCHAR(MAX)
BEGIN
    RETURN (
        SELECT 
            [Employee_Id] AS 'Id', 
            [Name] AS 'Name',
            JSON_QUERY((SELECT [dbo].[SelectChild_JSON]([Employee_Id]))) [Employees]
        FROM [Data]
        WHERE [Manager_Id] = @key
        FOR JSON PATH
    )
END
GO

SELECT 
    [Employee_Id] AS 'Id', [Name] AS 'Name',
    JSON_QUERY((SELECT [dbo].[SelectChild_JSON]([Employee_Id]))) [Employees]
FROM [Data]
WHERE [Manager_Id] IS NULL
FOR JSON PATH, ROOT( 'Employees')
GO

And the JSON:

{
    "Employees": [
        {   "Id": 1, "Name": "AMY",
             "Employees": [ { "Id": 2, "Name": "DANIEL" },
                            { "Id": 3, "Name": "EMILY"  },
                            { "Id": 4, "Name": "HANNAH",
                            "Employees": [  { "Id": 5, "Name": "JACK" },
                                            { "Id": 6, "Name": "JAMES",
                                            "Employees": [  { "Id": 7, "Name": "JESSICA" },
                                                            { "Id": 8, "Name": "JOSHUA"  }
                                                         ]
                                            }
                                        ]
                            }
                        ]
        },
        {   "Id": 9, "Name": "LAURA",
            "Employees": [  { "Id": 10, "Name": "LUKE" },
                            { "Id": 11, "Name": "MATTHEW",
                            "Employees": [  { "Id": 12, "Name": "OLIVIA" },
                                            { "Id": 13, "Name": "REBECCA",
                                            "Employees": [ { "Id": 14, "Name": "RYAN",
                                                           "Employees": [ { "Id": 15, "Name": "SOPHIE",
                                                                          "Employees": [ { "Id": 16, "Name": "THOMAS" }]
                                                                          }  
                                                                        ]
                                                            }
                                                        ]
                                            }
                                        ]
                            }
                        ]
        }
    ]
}

Nothing will change from the XML format regarding the complexity of processing and modifying.

HierarchyId Data Type

HiearachyId is the only real natively supported structure for handling hierarchical data in SQL Server. It’s implemented using CLR and you can read more on it in the documentation.

We will create [dbo].[Employees_Hierarchy_Id] where the [Path] column is of the HIERARCHYID type. Next, we will prepare the value for the [Path] column in a recursive CTE: [Employee_Id] column values will be converted to a string and contacted to form the path value which is then inserted into the [Path] column. the ‘All’ node will be created to make the example completed with one master node but this is just for demonstration, it will perfectly work with two parent nodes too.

CREATE TABLE [dbo].[Employees_Hierarchy_Id]
(
	[Employee_Id] INT NOT NULL PRIMARY KEY,
	[Name] NVARCHAR(100) NOT NULL,
	[Path] HIERARCHYID NOT NULL
	CONSTRAINT UC_Employees_Hierarchy_Id_Path UNIQUE NONCLUSTERED ([Path])
)
GO

;WITH [c] AS 
(
	SELECT [Employee_Id], [Name], CAST('/' AS NVARCHAR(MAX)) + CAST([Employee_Id] AS NVARCHAR(MAX)) + '/' [Path]
	FROM [#Source]
	WHERE [Manager] IS NULL

	UNION ALL
	
	SELECT [d].[Employee_Id], [d].[Name], [c].[Path] + CAST([d].[Employee_Id] AS NVARCHAR(MAX)) + '/' AS [Path]
	FROM [#Source] [d]
		INNER JOIN [c] ON [c].[Name] = [d].[Manager]
)
INSERT INTO [dbo].[Employees_Hierarchy_Id]
	(	[Employee_Id], [Name], [Path] )
	SELECT 
		[c].[Employee_Id], [c].[Name], [c].[Path]
	FROM [c]
GO

INSERT INTO [dbo].[Employees_Hierarchy_Id]
(	[Employee_Id], [Name], [Path] )
	SELECT 0, 'All', '/'
GO

SELECT 
	[h].[Employee_Id], [h].[Name], [h].[Path], 
	[h].[Path].ToString() [Path_String], [h].[Path].GetLevel() [Level],
	[p].[Name] [Manager_Name], [h].[Path].GetAncestor(1).ToString() [Manager_Path]
FROM [dbo].[Employees_Hierarchy_Id] [h]
	LEFT JOIN [dbo].[Employees_Hierarchy_Id] [p] ON [p].[Path] = [h].[Path].GetAncestor(1)
GO

Our hierarchy is now stored in the HIERARCHYID datatype column. We have also concerted the binary path value to human-readable form using the .ToString(). Please note the .GetLevel() function returning at which level the current node is. Then .GetAncestor() function was used to get the right Manager name.

We can use the recursive CTE similarly to the options above and build the real path visually:

;WITH [c] AS (
	SELECT [Employee_Id], [Name], [Path] [Parent_Path], CAST('/' + [Name] AS NVARCHAR(MAX)) [String_Path]
	FROM [dbo].[Employees_Hierarchy_Id]
	WHERE [Path].[GetAncestor](1) = 0x

	UNION ALL

	SELECT [eh].[Employee_Id], [eh].[Name], [Path], [c].[String_Path] + '/' + [eh].[Name]
	FROM [dbo].[Employees_Hierarchy_Id] [eh]
		INNER JOIN [c] ON [eh].[Path].[GetAncestor](1) = [c].[Parent_Path]
)
SELECT *
FROM [c]
GO

There is much more fun we can do with the HIERARCHYID data type column. It’s mostly compared to the Parent/Child approach. You should check it in the documentation or internet for usage/performance comparison and carefully decide which option will better fit your needs.

Graph

Grap–databases capabilities were added to SQL Server 2017 version. They are primarily designed to support the persistence and querying of complex relationships in data. But we can use it for parent-child relations too.

Lets create [dbo].[Employees] as NODEs table and [dbo].[IsManagerFor] as EDGE table. The NODEs table will store just a list of all employees. The EDGEs table will persist relations between employees. It’s very similar to the concept of moving the hierarchy outside of the primary table in the Closure tables chapter above.

CREATE TABLE [dbo].[Employees] (
    [Employee_Id] INT PRIMARY KEY,
    [Name] NVARCHAR(100) NOT NULL
  ) AS NODE
GO

CREATE TABLE [dbo].[IsManagerFor] AS EDGE;
GO

INSERT INTO [dbo].[Employees]
	( [Employee_Id], [Name] )
	SELECT 
		[Employee_Id], [Name]
	FROM [#Data]
GO

INSERT INTO [dbo].[IsManagerFor]
	( $from_id, $to_id )
	SELECT 
		(SELECT $node_id FROM [dbo].[Employees] WHERE [Employee_Id] = [d].[Employee_Id]),
		(SELECT $node_id FROM [dbo].[Employees] WHERE [Employee_Id] = [d].[Manager_Id])
	FROM [#Data] [d]
	WHERE [d].[Manager_Id] IS NOT NULL

SELECT * FROM [dbo].[Employees]
SELECT * FROM [dbo].[IsManagerFor]
GO

If we will select nodes and edges new columns are presented: $node_id column is basically the new graph-specific unique id of an Employee. The edge is just and relation $from_id to $to_id node.

We can use the graph MATCH() function in WHERE clause to get a Manager for each Employee.

SELECT [e1].[Employee_Id], [e1].[Name] [Employee], [e2].[Employee_Id] [Manager_Id], [e2].[Name] [Manager]
FROM [dbo].[Employees] [e1], [dbo].[IsManagerFor], [dbo].[Employees] [e2]
WHERE MATCH([e1]-([IsManagerFor])->[e2])
GO

Recursive CTE can be used to get the hierarchy visually:

;WITH [c] AS 
(
	SELECT [e].$node_id [Node_Id], [e].[Employee_Id], [e].[Name], 1 [Level], [m].$from_id [Parent_Node_Id],  CAST([Name] AS NVARCHAR(MAX)) AS [Path]
	FROM [dbo].[Employees] [e]
		LEFT JOIN [dbo].[IsManagerFor] [m] ON [e].$node_id = [m].$from_id 
	WHERE [m].$to_id IS NULL

	UNION ALL
	
	SELECT 
		[e].$node_id, [e].[Employee_Id], [e].[Name], [c].[Level] + 1, [m].$to_id, [c].[Path] + '->' + [e].[Name]
	FROM [dbo].[IsManagerFor] [m]
		INNER JOIN [dbo].[Employees] [e] ON [m].$from_Id = [e].$node_id
		INNER JOIN [c] ON [c].[Node_Id] = [m].$to_Id
)
SELECT *
FROM [c]
ORDER BY [c].[Employee_Id]
GO

See graph specific nodes in the list:

You will aks probably where is the advantage to other options in this simple case. There is none. The EDGEs table is just a dedicated table like in the case of closure tables. The real value will come in the case of multiple different relations ships between employees (i.e. adding IsFriendOf). I will recommend this article to start with.

That’s all for now. I was trying to keep it as simple as possible to just demonstrate available options.

I will maintain this list of links over time for you to get more in-depth.

Links

Adjacency list (Parent/Child)

• https://en.wikipedia.org/wiki/Adjacency_list
• https://blog.duncanworthy.me/sql/hierarchical-data-pt1-adjacency-list/
• https://explainextended.com/2009/09/25/adjacency-list-vs-nested-sets-sql-server/
• https://www.sqlservercentral.com/articles/hierarchies-on-steroids-1-convert-an-adjacency-list-to-nested-sets

Closure tables

• https://www.red-gate.com/simple-talk/databases/sql-server/t-sql-programming-sql-server/sql-server-closure-tables/

Nested sets

• https://www.sqlservercentral.com/articles/hierarchies-on-steroids-2-a-replacement-for-nested-sets-calculations-1

HierarchyId

• https://docs.microsoft.com/en-us/sql/t-sql/data-types/hierarchyid-data-type-method-reference?view=sql-server-ver15
• https://docs.microsoft.com/en-us/sql/relational-databases/tables/tutorial-using-the-hierarchyid-data-type?view=sql-server-ver15
• https://www.sqlshack.com/use-hierarchyid-sql-server/
• https://blog.matesic.info/post/HierarchyID-data-type-performance-tips-and-tricks

Graph

• https://www.red-gate.com/simple-talk/databases/sql-server/t-sql-programming-sql-server/sql-server-graph-databases-part-1-introduction