http://www.dealsghost.com

Director
Sales Mgr
Region 1 Mgr
Employee 3
Employee 4
Employee 5
Region 2 Mgr
Subregion A Mgr
Employee 6
Employee 7
Subregion B Mgr
Employee 8
Employee 9
Secretary
Treasury Mgr
Employee 1
Employee 2

The level two employees are Sales Mgr, Secretary and Treasury Mgr, in that order.
Under the Sales Mgr is Region 1 Mgr and Region 2 Mgr, in that order, and so on.
They must be sorted alphabetically regardless of the sequence in which they were added to the table. Sorting by the primary key is not a good idea.

The reason why kod34fr33`s Region 2 Mgr sorted before Region 1 Mgr is that /1/6/11/ is alphabetically before /1/6/7/.
One can achieve an alphabetic sort within a depth level, by adding a `sort` column to the helper table. The sort column must be built the same way as the path column, but using employee.name rather than emp_id and adding a few lines to the triggers.

The sort keys for Region 1 Mgr and Region 2 Mgr would then be “/Director/Sales Mgr/Region 1 Mgr” and “/Director/Sales Mgr/Region 2 Mgr”
and when the same select is done but using “order by p.sort” the results are sorted alphabetically within each level.

I would not be concerned about the fact that the sort column will hold long strings. These hierarchy tables are typically static lookup tables with relatively few rows (compared to business transaction tables which grow every day), so disk space is not a serious consideration.

Is the reason for the second helper table to avoid table mutating problems on the triggers? Otherwise the `path` could just be another column in the employee table.

I think your triggers should read after insert and before update in EMPLOYEE rather than on SITE.

Maybe your note about “node weight” to fix the sort order can be solved by adding columns to the order by clause, eg order by p.path ASC,p.name ASC

Shameful, really.

Regards from india

Thank you very much for you work.
using a helper table quite an nice approach id one wants to go with the adjacency list model.
However, I’ve got one question:
In your first trigger you use the following select:
“SELECT `path` INTO `parent_path` FROM `employee_path` WHERE `emp_id` = NEW.`emp_id`;”
As the trigger starts “AFTER INSERT”, I ask myself how there can ever be a result for that query?
An employee with the emp_id of the employee just inserted into the “employee”-table will never be found in the path-table.
I suppose if you changed this to “SELECT `path` INTO `parent_path` FROM `employee_path` WHERE `emp_id` = NEW.`emp_parent_id`;” it should work.
Thanks again,

/dev/null

/dev/null
After read Joe Celko’s book and Tropashko’s article, my approach more relevant to call as materialized path a.k.a path enumeration than adjacency list.
and you are right about the trigger. that’s my mistake. thanks for pointing that out. –kod34fr33