Generate Hierarchy value automatically

Question

I have a tree table with column ID, ParentID and Hierarchy and want to generate Hierarchy column value dependent by ParentID. for this purpose I use triggers. do exists better way to generate Hierarchy column value?

ALTER TRIGGER [TR_MyTable_BeforInsert] ON [MyTable]
INSTEAD OF INSERT
AS BEGIN
SET NOCOUNT ON;
Declare @Name NVarChar(100),
        @ParentID Int

Declare DACategory Cursor For
Select  A.Name, A.ParentID
From    Inserted A
OPEN    DACategory
FETCH NEXT FROM DACategory INTO @Name, @ParentID
While @@FETCH_STATUS=0 Begin

    Insert Into MyTable (Name, ParentID, Hierarchy)
    Values (@Name, @ParentID, dbo.F_MyTableGetHID(NULL, @ParentID))

    FETCH NEXT FROM DACategory INTO @Name, @ParentID
End
Close   DACategory
Deallocate DACategory
END

Function :

ALTER FUNCTION [F_MyTableGetHID]
(
    @ID int,
    @ParentID int
)
RETURNS HierarchyID

AS BEGIN
    Declare @RootHID HierarchyID, 
            @LastHID HierarchyID

    IF (@ParentID IS NULL)Begin
        Set @RootHID = HierarchyID::GetRoot()
        Select @LastHID = Max(Hierarchy) From MyTable Where ParentID IS NULL
    End Else Begin
        Select @RootHID = Hierarchy From MyTable Where ID = @ParentID
        select @LastHID = Max(Hierarchy) From MyTable where ParentID = @ParentID
    End
    return @RootHID.GetDescendant(@LastHID, NULL)
END

for Update this table also have trigger to set Hierarchy column again when ParentID Changed.

what's the best practices for this problem?

EDIT 1 : I look up solution that not use trigger if possible.

Answer 1

I have a different approach to answer both the questions. I generally avoid using triggers until it is the last choice as it adds un-necessary overhead on the database.

Comparision between triggers and stored procedure

• It is easy to view table relationships , constraints, indexes, stored procedure in database but triggers are difficult to view.
• Triggers execute invisible to client-application application. They are not visible or can be traced in debugging code.
• It is easy to forget about triggers and if there is no documentation it will be difficult to figure out for new developers for their existence.
• Triggers run every time when the database fields are updated and it is overhead on system. It makes system run slower.

Enough said, this is why I prefer stored procs. You can create a job file (say for ex : it executes after every 30 min, or any other time) via agent. You can use the logic for insertion in that job file. In this way your data in the tree table would be near to real time.

now reference to create an agent :
http://msdn.microsoft.com/en-us/library/ms191128(v=sql.90).aspx
http://msdn.microsoft.com/en-us/library/ms181153(v=sql.105).aspx

Answer 2

You asked for the best practice.

The best practice is not to use the adjacency list model (which is what you have) and instead switch to the nested set model.

It's more difficult to code and understand, which is why it's not as popular, but it's much more flexible.