Имеется дерево подразделений примерно из 3500 узлов. Вложеность примерно 5-7 уровней. Имеется постоянная потребность искать инфу о списке родителей узлов. Дерево довольно активно трансформируется: добавляются узлы, старые узлы меняют свое содержимое. Конечный потребитель на фронте получает данные в виде JSON, где child отсортированны по алфавиту.
Стал вопрос в каком виде это счастье хранить. Есть 2 подхода:
1. parent_id. Попытка построить дерево на стороне SQL ничего хорошего не дала. Рекурсия на стороне SQL работает долго. Ок. 2 секунд. В итоге отдаю дерево в виде отсортированного по глубине списка. Само дерево строится на фронте. Запрос работает быстро. Доделка дерева на фронте ок. 0.016 сек. Т.е. довольно живенько
2. hierarchyid. Зверь незнакомый. Но имеющий, судя по всему много плюсов. Во всяком случае, поиск родителей работает проще. Но один момент меня смутил. Как вставлять узлы. Для вставки необходимо знать номера узлов-соседей и вычислять номер в иерархии для нового узла.
Первый вариант меня вполне устраивает, но грызут сомнение, что я упускаю шанс упростить работу с данными. Что вы можете порекомендовать в моем случае? Стоит ли связываться с hierarchyid?

Поиск происходит как раз от чилда к родителю.
А не подскажете решение моего вопроса касающегося вставки узла? Или ссылочку на него. Ведь, если я правильно понимаю, дерево мне надо хранить отсортированным. И если я буду вставлять узел, то вставлять в хвост цепочки -- не вариант. Надо втюхивать как внутренний элемент цепи. И тут надо вводить дробные индексы. Типа так:
1, 2, 3, [3.5], 4
Еще вставочка:
1, 2, 3, [3.25], 3.5, 4
Еще вставочка:
1, 2, 3, [3.15], 3.25, 3.5, 4
И т.д.
Я правильно понимаю?

Спасибо за ссылку. Вроде и читал доку, но примера не помню. :о(
А не могли бы вы обосновать почему hierarchyid и чем?
И кроме того, можно ли при его помощи быстро построить JSON на стороне SQL, или все-же придется возвращать отсортированный по глубине и именам лист, чтобы собирать его на фронте?