Очень интересный подход
Правда прямо не говорится про недостатки (по сравнению с тем же id/parentId подходом):
- вставление нового элемента превращается в апдейт в среднем половины записей в базе (против 1 insert-а в случае id/parentId подходе)
- алгоритм нахождения непосредственных детей или непосредственного родителя (т.е. только с одного уровня) становится нетривиальной задачей (против 1-ого простого select-а в id/parentId)
- алгоритм переноса группы из одного места в другое становится нетривиальной задачей (против 1-ого update-а в id/parentId подходе).
выигрыш (правда существенный) имеется только при выборках данных и удалении ветки (где классический подход лажает по полной).
Мне на ум приходило некое, компромиссное между этими двумя вариантами, решение - поддерживать избыточную таблицу id / parentId / distance - где хранятся связи между каждым родителем и его детьми, для любого уровня вложенности (distance = 0, если родитель является непостредственным родителем, =1 если через одного и т.д.)
В этом случае вставка выполняется за 2 insert-а, выборка всех детей/родителей (как произвольной вложенности, так и до заданного уровня вложенности) - за 1 select, перемещение из группы в группу - нетривиальной задачей, удаление - за 2 delete.
Но как ни крути - в рамках реляционных баз деревья - это гимор. По моему при любой организации таких структур всегда какая то из операций над ними будет "нетривиальной". Тут надо исходить из того какие из операций будут выполняться реже других
