Смотрите, в языке запросов 1С есть отличный оператор  сравнения "В ИЕРАРХИИ".
В объектной модели есть метод МенеджераСправочника ВыбратьИерархически().

Если бы этих операторов не было, а Также не было бы специализированного типа СправочникВыборка, как бы вы реализовывали эти вещи?

Ну то есть например был бы оператор В, или можно было только выбрать элементы/группы непосредственноого подчиненния. Структура, Соответствие и Массив в вашем распоряжении также...  Как бы вы делали?

(0) а как скуль делает с 1Сным запросом?

nested sets

2(0) Я не знаю. Подозреваю что рекурсия, но не хотел этого произносить. Вдруг кто лучше знает.

2(2) Это для СправочникВыборка? Ну он кажется проще немного, там просто идет однонаправленный перебор. Влоэженные множества - самое близкое это вложенные соотвествия в 1С?

Выбрать иерархически нужно, чтоб в виде дерева или достаточно порядка по иерархии?

Опять же есть несколько реализаций хранения иерархии.
В 1с выбрали простой для хранения, но сложный для выборки

(4) ты спрашиваешь мнение, а потом с ним споришь. Зачем?

2(5) Ну выборкаиерархически возвращает это по сути однонаправленный список, то есть нет там иерархии. просто можно узнать уровень в выборке. Ну и еще оптимизация - он не сразу весь возвращает, а постепенно. то есть на самом деле оно работает по другому, чем если мы выполняем запрос с В ИЕРАРХИИ, и потом выгрузим его в какую-то структуру.

2(7) Ну хорошо, не спорю. Тогда почему?

Иерархия в базе данных

(9)+ решение в 20 и 21
Иерархия в базе данных

2(10) О, спасибо

2(10) а, ну то есть ты решил добавить полный путь по сути...
Ну хорошо.
Но вот ты говоришь - *добрая фея* - это что? типа фоновое задание? или тригер? Ему-то все равно нужно пройтись по всем родителям до корня, то есть все-таки рекурсия есть.

(12) Тригер (подписка на событие)

(12) Там не просто полный путь, там полный путь с номерами уровней, поддающийся сортировке.

(14)* пардон, с номерами позиций внутри уровня.

2(15) да, я понял, сенкс.

Старенькая, но всё ещё актуальная статья - https://rsdn.org/article/db/Hierarchy.xml

(2) Этот способ хранения дерева очень плох с точки зрения записи. На больших количествах записей смерть производительности.

2(18,2) К сожалению или к счастью, это то что мой ОРМ-фреймворк предлагает из коробки. Таблица в принципе не большая, 1500 записей.
Так что да, наверно им и воспользуюсь.  А выбратьИерархически - да, все равно нужно будет для каждого парент выбирать нестед сет до тех пор, количество потомков не перестанет увеличиваться...

2(2) Короче, да. Идеально зашло.
Просто во-первых забыл почему-то, что при записи, когда у чайлда устанавливаю ссылку на родителя, то у родителя вложенный сет на детей апдейтится (я от этого абстрагирован, оно само).
Во-вторых пока не начал делать, почему-то казалось сложно.

(0) если бы да кабы...
ЗАЧЕМ ?

(21) Гештальт закрыть, а что?

(8) потому, что мне нравится