I might have to take over/recreate a specific Forum. And it would be a "really nice to have" feature if the posts of each thread were structured in a Heirarchical Tree.

Now I noticed that Heirarchical Post Structure is really, really rarely used for Forums. MSDN is one of the few examples I know. Otherwise I have only seen this structure for comment systems but there it is most common.

Even MSDN tries to limit the number of answers per thread somewhat (via the "only question per thread" rule). What I would have to make will need a tree structure consisting of easily 100 nodes/thread. With leaf structures 10-20 generations deep. If I do choose tree structure it's per thread scale would be bigger then MSDN or any comment system I have seen.
The original system limited the DB server load by only loading the title of each post, putting loading the actuall post off until the user requested it via the Web GUI (some java/ajax control I think).

My DB experience is limited mostly to Relational databases. Tree structures I have so far only used for basic XML, HTML, XAML and similar markup languages. I never used a Heirarchical DB before, but I do know how to simulate such a structure in a Relational Database. I even have some ideas to make it more manageable (making each thread and possible each top level post it's own tree).
I am just not certain I should, as it is a totally new area and the task seems a bit bigger scale then anything else I see on the internet.
Are there any good resource for teaching a Relational DB programmer to use Heirarchical Structures/DB engines?
Is SQL a good engine for Heirachical Data?
Are there any other good Heirarchical DB engines?
Maybe even a good Heirarchical CMS/pre written Forum system I could just start from?

As  you probably know since SQL Server 2008 we can use HierarchyID system data type along with a variety of
 system methods is designed to make it easier to store, query,
 modify and work with hierarchical data. This new data type is
 optimized for displaying data trees. The HierarchyID data type 
supports two strategies for index storage. They are called depth-first 
and breadth-first. In depth-first, rows in a single tree are stored 
close to each other in the index. An original chart type data with employees
 and managers is a typical example. In breadth-first, the rows are stored next
 to each other. In the employee / manager example, the employees who report
 to the same manager would be stored next to each other.

There are several system functions and methods associated with the
 HierarchyID data type. Some include GetLevel(), ParentChildOrg(),
 DescendantLimit() and GetAncestor(). The example below shows 
a simple example of a parent child relationship between managers and employees.


CREATE TABLE Organization
   (
 NodeLevel hierarchyid,
    EmployeeID int,
    OrgLevel as NodeLevel.GetLevel(), 
    EmployeeName nvarchar(50) NOT NULL
   ) ;
GO
insert into Organization
(NodeLevel, EmployeeID,  EmployeeName)
values
(hierarchyid::GetRoot(),0,  'Bob')
go
Declare @Manager hierarchyid
SELECT @Manager = hierarchyid::GetRoot()
FROM Organization ;

insert into Organization
(NodeLevel, EmployeeId,  EmployeeName)
values
(@Manager.GetDescendant(null, null), 1, 'Joe')
go
Declare @Manager hierarchyid
declare @NodeLevel hierarchyid

select @NodeLevel = NodeLevel 
from Organization 
where EmployeeName = 'Joe'

SELECT @Manager = max(NodeLevel)
FROM Organization
where NodeLevel.GetAncestor(1) = @NodeLevel

insert into Organization
(NodeLevel, EmployeeID,  EmployeeName)
values
(@NodeLevel.GetDescendant(@Manager, null),2,  'Sarah')
go
select NodeLevel.ToString()as NodeLevel_String, *
FROM Organization
go
drop table Organization
go

Hi Chris,

Please go through this pdf. I found it useful

http://ebooks.cawok.pro/Morgan.Kaufmann.Joe.Celkos.Trees.and.Hierarchies.in.SQL.for.Smarties.May.2004.eBook-DDU.pdf