Всем здоровья! Что-то туплю с запросом. Есть массив номенклатуры, нужно получить рядом с каждой ее верхний уровень иерархии. С одним элементом понятно, а с массивом?
Делаю так для одного элемента:

ВЫБРАТЬ
    Номенклатура.Ссылка КАК Ссылка
ИЗ
    Справочник.Номенклатура КАК Номенклатура
ГДЕ
    Номенклатура.Ссылка = &Ссылка
ИТОГИ ПО
    Ссылка ТОЛЬКО ИЕРАРХИЯ

А если массив? Нужно получить:

Номенклатура1 - Группа1
Номенклатура2 - Группа2
Номенклатура3 - Группа1

(0) это тест на собеседовании ?

Что значит верхний уровень? Верхний уровень у всех элементов один.

(2) Ни в коем случае. Есть просто верхний, а есть САМЫЙ верхний...
Ну как в анекдоте про технику безопасности :
"Синюю краску пить нельзя!!! А зеленую - пить нельзя НИКОГДА!!!"

в общем случае запросом никак, при ограничении иерархии возможно через ЕстьNULL(Ссылка.Родитель.Родитель.Родитель....., ЕстьNULL(Ссылка.Родитель.Родитель.Родитель....., ЕстьNULL()))

или можно рядом в РС хранить nested set + level и выбирать через простое условие Лев меньше и Прав больше и Уровень = 1

(1) Нет, оптимизирую код. Сейчас делается в цикле по каждому элементу массива запрос.
(2) Запрос выше выдает иерархию элементов. Например, структура справочника Группа1/Группа2/НашЭлемент.
Запрос выдает эти значения построчно:
Группа1
Группа2
НашЭлемент

Нужна Группа1 - НашЭлемент

еще можно в РС хранить верхнего родителя и в подписке обновлять.

(4) (5) Ясно, жаль. Хотелось красоты) Спасибо!

(7) Железобетонный вариант :D

у эльдаровича есть красивое решение через временые таблицы

(10) не красивое и не производительное.

(11) Концептуально - красивое.

(11) Да и если иерархия сложная с длинными путями - то очень эффективное для алгоритмов покрывающих большую часть справочника.

Что-то (4) явно брешет, что запросом никак

(14) ой ли?

если рядом положить данные для nested set то и соединение по В Иерархии можно, и верхнего родителя и хоть черта лысого. а в стандартном 1совском adjastent list нифига нет общего случая, разве что на расширенном (t-/pl-)sql, а не на 1совском обрубке.

(11) Да нормальное у него решение.
И довольно неплохо отрабатывает. Просто немного его подправить под задачу.
(0) У меня около года назад был такой вопрос. Решение с транзитивным замыканием помогло. Выбирает оно, конечно, много ненужных данных, но в последнем запросом ограничиваешь выборку и все есть. Производительность не самая высокая, так что нужно сравнивать твое решение с циклом и замыкание по быстродействию.
При малом размере массива будет довольно медленно, но все надо проверять.

(15) Если знать максимальную глубину, то никакой проблемы сделать одним запросом. А если использовать вариант Ильдаровича - то можно даже и не знать. Так как там экспоненциальная зависимость и можно использовать решение, которое заведомо перекроет все разумные практические варианты.

(18) "если знать максимальную глубину", то нужно сначала её определить, а потом сделать динамический текст запроса и его выполнить. что в этом элегантного - хз.

(19) Максимальную глубину можно выставить в метаданных и оттуда брать. На практике для конкретных справочников всегда существуют разумные пределы. А одним пакетом - повышает эффективность.
А прям элегантных решений этой задачи не существует в природе. Ну или делись.

(20) прям элегантное - положить рядом что-то, что для этого предназначено. materialized path в запросе 1с, к сожалению, бесполезен, nested set может помочь. Но это требует дополнительных подписок, хоть и позволяет кучу всего. в данном конкретном случае проще всего (7), если прям нешуточная борьба за производительность идет.

(21) В каком виде положить? Комбинации всех путей, что ли, хранить?
Читать-то элегантно, а вот обновлять - как-то не очень. Эдак перенос группы может вести к перезаписи половины регистра.

(22) +100500
А вообще, тут вопрос только в том, что нам нужно. Производительность или простота.

(21) А самая смешная фигня получится - когда для ускорения пересчета nested sets ты начнешь использовать вариант Ильдаровича :)

(22)
>Комбинации всех путей, что ли, хранить?
nested set работает не так

Вообще я не говорю, что минусов нет. да, пересчеты могут быть всей таблицы при изменении иерархии. на sql с его update еще куда ни шло (по количеству запросов, по строкам все равно швах).
У себя использовал для хранения альтернативных иерархий с фоновым обновлением. и только для групп, на элементы справочника не распространял. Тогда самих строк у иерархии сильно меньше получается.
Зато к СКД прикручивается замечательно, и соединения всякие работают.

Пересчета nested set однократно-рекурсивным проходом полной выборки делал. с перезаписью только нужных данных.

(25) Это было по (7) уточнение. А nested set - пичалька с точки зрения пересчета. Печальнее остальных вариантов. Читать - да, красиво.

(0) а что за субд ? Может какой нить коннект бай приор найдётся ?

(0) На инфостарте есть статья "транзитивное замыкание", там рассмотрен пример того, как получить родителя верхнего уровня запросом. Посмотри, довольно интересное решение, а главное очень быстро отрабатывает.

(0) Вали через

Выбор когда Номенклатура.Родитель = хыхыхы Тогда  и погнали