I wanted to use the new HierarchyID type in SQL Server 2008 to handle the page relations in a small wiki application. However It would need to have multiple root nodes since every main article/page per account would be a root node.
From what I have read the HierarchyID type only allows 1 root node per column is this correct? and is there any way to enable multiple root nodes ?
Yes, you are reading right - using the HierarchyID allows only one single root node. That's the way it is and there's no way around it, as far as I know, short of introducing an artificial new "über-root" which serves no other purpose than to allow you to have several first-level "sub-root"....
Marc
Update: as Greg (@Greg0) has pointed out - this answer is actually not correct - see his answer for more details.
I've been doing some testing, and it appears you do not need a record with a root hierarchyid.
For example, normally you would one root node (level 1) and multiple childen, but you can skip the root node, having no root records, just records that start at level 2:
//table schema
CREATE TABLE [Entity](
[ID] [int] IDENTITY(1,1) NOT NULL,
[Name] [varchar](50) NOT NULL
[Hierarchy] [hierarchyid] NOT NULL,
CONSTRAINT [PK_Entity] PRIMARY KEY CLUSTERED
(
[ID] ASC
)
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
//Insert first 'root', which is technicall a child without a parent
INSERT INTO [Entity]
([Name]
,[Description]
,[Hierarchy])
VALUES
('Root A'
,hierarchyid::GetRoot().GetDescendant(NULL,NULL))
//Create the second 'root'
INSERT INTO [Entity]
([Name]
,[Hierarchy])
VALUES
('Root B'
,hierarchyid::GetRoot().GetDescendant((select MAX(hierarchy) from entity where hierarchy.GetAncestor(1) = hierarchyid::GetRoot()),NULL))
Now if you select all rows from the table, you see:
SELECT [ID]
,[Name]
,[Hierarchy],
[Hierarchy].ToString()
FROM [Entity]
ID Name Hierarchy (No column name)
1 Root A 0x58 /1/
2 Root B 0x68 /2/
I'm not sure if this would be recommended practice but conceptually it allows you to have multiple roots, as long as you consider the 2nd level in the tree as the root
What I do to make unique root nodes is just cast your table PrimaryKey as a HierarchyId on your desired anchor records, e.g.
Given a pretend table having ArticleID | ArticleID_Parent | Hierarchy, you can tweak all "roots" to become unique like this;
UPDATE [Article]
SET Hierarchy=CAST('/'+CAST([ArticleID] as varchar(30))+'/' AS hierarchyid)
WHERE [ArticleID_Parent]=0
.. then to get the "branch" of a particular root;
SELECT * FROM [Article]
WHERE Article.Hierarchy.IsDescendantOf((SELECT Hierarchy FROM Article WHERE ArticleID=XXXX)) = 1
The hierarchyid data type that can be used to represent a position in a hierarchy. It does not inherently enforce the hierarchy though. This is an extract from the MSDN documentation for hierarchyid.
It is up to the application to generate and assign hierarchyid values in such a way that the desired relationship between rows is reflected in the values.
This example shows how a combination of a computed column and a foreign key can be used to enforce the tree.
CREATE TABLE Org_T3
(
EmployeeId hierarchyid PRIMARY KEY,
ParentId AS EmployeeId.GetAncestor(1) PERSISTED
REFERENCES Org_T3(EmployeeId),
LastChild hierarchyid,
EmployeeName nvarchar(50)
)
GO
In your case, you would modify the computed column formula so that for root records either Null (foreign keys are not enforced for Null values in SQL Server) or perhaps the unmodified hierarchyid of the record (roots would be their own parents) would be returned.
This is a simplified version of the above example which goes with the strategy of assigning root nodes a null ParentId.
create table Node
(
Id hierarchyid primary key,
ParentId AS case when Id.GetLevel() = 1 then
Null
else
Id.GetAncestor(1)
end PERSISTED REFERENCES Node(Id),
check (Id.GetLevel() != 0)
)
insert into Node (Id) values ('/1/');
insert into Node (Id) values ('/1/1/');
insert into Node (Id) values ('/'); --Fails as the roots will be at level 1.
insert into Node (Id) values ('/2/1/'); --Fails because the parent does not exist.
select Id.ToString(), ParentId.ToString() from Node;
Only the valid inserts from above succeed.
Id ParentId
/1/ NULL
/1/1/ /1/
Yes you can have multiple roots.
There is no database engine restriction on multiple roots. But of course you need a discriminator when selecting. Consider the following which uses 'Division' as the discriminator:
CREATE TABLE [EmployeeOrg](
[OrgNode] [hierarchyid] NOT NULL,
[OrgLevel] AS ([OrgNode].[GetLevel]()),
[EmployeeID] [int] NOT NULL,
[Title] [varchar](20) NULL,
[Division] [int] not null
) ON [PRIMARY]
GO
Insert into EmployeeOrg (OrgNode, EmployeeID, Title, Division) values ('/', 1, 'Partner A', 1 );
Insert into EmployeeOrg (OrgNode, EmployeeID, Title, Division) values ('/1/', 2, 'Part A Legal', 1 );
Insert into EmployeeOrg (OrgNode, EmployeeID, Title, Division) values ('/1/1/', 3, 'Part A Legal Asst', 1 );
Insert into EmployeeOrg (OrgNode, EmployeeID, Title, Division) values ('/', 4, 'Partner B', 2 );
Insert into EmployeeOrg (OrgNode, EmployeeID, Title, Division) values ('/1/', 5, 'Partner B Legal', 2 );
Insert into EmployeeOrg (OrgNode, EmployeeID, Title, Division) values ('/1/1/', 6, 'Partner B Legal Asst', 2 );
SELECT *
FROM EmployeeOrg
WHERE OrgNode.IsDescendantOf('/') = 1 and Division = 1
SELECT *
FROM EmployeeOrg
WHERE OrgNode.IsDescendantOf('/') = 1 and Division = 2
This returns the two different hierarchies as expected.
can't you just have one, 'non-displayed' root and have all main articles at level 1?
