Получение группы верхнего уровня #414473

Столкнулся со следующей задачкой: есть справочник, в котором вид иерархии - иерархия элементов, ограничения на количество уровней нет. Нужно в одном запросе получить, зная элемент n-го уровня, элемент 0-го уровня. Программно получить группу не составляет особого труда, а вот в запросе сложно. В общем, нетривиальная задачка. У кого какие мысли?

Динамический запрос в зависимости о уровня элемента

ПолноеНаименование

поподробнее ;) и что?

+ мозг

дико извеняюсь, секция v8 или запросы и построители

все равно

ПолноеНаименование - и что??? как это может помочь?

элементом 0-го уровня всегда будет пустая ссылка...

и зачем все это надо?

и бред, так как и Уровень и ПолноеНаименование методы, система так же обратится к базе данных и будет по ссылкам искать родителей, то есть вместо того чтобы получить сразу ссылку будет куча ненужных телодвижений

есть предложения?

Одним запросом никак, если нет ограничения на уровни, идеально добавить реквизит РодительПервогоУровня, подписаться на ПередЗаписью и фигачить его туда, а взапросе потом спокойно получать

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

цикл Пока номенклатура.владелец не пустой выбрать номенклатура.владелец где номенклатура.элемент = &елемент элемент = номенклатура.владелец конец цикла вот так можно сделать)

хочется одним запросом, чтобы без лишних телодвижений =)

у меня просто есть хороший оптимизированный запрос, а этот момент слабое место в нем...вот и задался такой целью

может действительно ПолноеНаименование? Синтаксис: ПолноеНаименование Возвращаемое значение: Тип: Строка. Строка, включающая наименование элемента и наименования всех вышестоящих элементов. Наименования выводятся слева направо, начиная с самого верхнего уровня, разделяются символом "/". Описание: Получает наименование элемента справочника с учетом наименований всех вышестоящих элементов. Пример: Сообщить("Полное наименование данного элемента: " +          СсылкаНаЭлемент.ПолноеНаименование);

пачка запросов тебе поможет

+12 Хотя если б я писал не тиражное решение, то примерно проанализировал бы какой может быть уровень и написал бы запрос в виде Родитель, Родитель.Родитель, Родитель.Родитель.Родитель, и т.д. по числу наиболее вероятного максимального уровня, в крайнем случае обратился бы рекурсивно

и забрать до "/" ;-)

Что тебе по 12 понятно? В 12 как раз единственный вариант, когда гарантированно одним запросом без лишних телодвижений

и причем здесь владелец? :) динамически по количеству уровней иерархии добавить в текст запроса Родитель = "| Номенклатура.Родитель"; ТекстЗапроса = ТекстЗапроса + Родитель + " Как Родитель1, " пока ... выборка по уровням иерархии начиная со второго  ТекстЗапроса = ТекстЗапроса + Родитель + ".Родитель Как Родитель" + СчетчикЗапроса может типа так?

+22 только остается проверять на нулл :((

Символ "/" не является запрещенным, т.е. вполне может встретиться и в наименовании, а автор такого "кода" - сам понимаешь, в чем.

+23 зато уже без обращений к базе :)

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

+ соответственно поля Элементи СамыйВернийПапа. Идея думаю понятна?

Какое кол-во бредятины, боже мой Интересно только 18 послушать

знаю глупый способ: 1. Получить ТЗ с двумя колонками "Родитель0" и "Родитель", в Родитель0 будут группы верхнего уровня, в Родитель -все подчиненные им 2. Загнать ТЗ во временную атблицу и соединять в запросе по равенству родителя твоего элемента справочника полю Родитель ил ТЗ

ты, окромя раздуть базу на поле , ничего не предложил... или я ошибаюсь?

по В ИЕРАРХИИ работает очень долго для больших справочников

я так использовал получение:

Я предложил все возможные варианты, в т.ч. и 19, возможно только в 18 что-то интересное, так как пакеты не знаю. Теперь по поводу "Раздуть базу". На сколько раздуется база при 100 тысячах элементов при добавлении ссылочного поля?

да уж Пачка запросов - как звучит!!! Пачка - тачка. :)

да тоже через .опу таксказать ИМХО эффективней всего это реквизит с родителем 1го уровня а лучше вообще отказаться от такого алгоритма

Этот вариант получит гран-при как самый тормозной из всех возможных

1 раз можно :).

Моё ИМХО такое же, либо 19 если с вероятностью в 90%(что скорей всего) можно будет узнать реально используемое количество уровней.

да и сомнительно, что справочник подразделения см. может быть уж таким огромадным. Не номенклатура все таки.

упс не , а .

звиняю, 19 не заметил а вот по поводу - раздуть базу, просто надо узнать постановку задачи - если отчет формируется раз в месяц, то и смысла хранения доп информации не вижу...

возможно прав

для сравнения этого варианта первоначально использовалось  В ИЕРАРХИИ , после того как справчник дорос до 500-600 тыс объектов... отрабатывало оч медленно при использовании этой ф-ии тормозов не наблюдается

Да.

что-то не пойму... а первые 1 не рулит??

Согласен, гран-при таки за ВИЕРАРХИИ, твой вариант второе место при 500-600 тысячах :)

как в будет тяжеловато сделать при отсутствии ограничения по уровням см. .

Жизнь не удалась :)

Я несколько раз написал - в большинстве случаев на конкретной фирме реальный уровень вложенности чаще всего известен.

здесь идет речь конкретно о справочнике подразделения см. . Как то тяжелоа представить организацию с 500 - 600 тыс. подразделений :)

гы... уел ))

а можно немного урезать (кроме того, что подчинение может быть не только группе) и с учетом того, что эта функция должна вызываться тока для элементов справочника с уровнем не равным 0:

Это вообще-то реализовано в типовых и циклом а не рекурсией

опс ошиься чуть. [1С] Функция ПолучитьВерхнегоРодителя(Ссылка)        Если Ссылка.Родитель.Пустая Тогда             Возврат Ссылка;        Иначе             Возврат ПолучитьВерхнегоРодителя(Ссылка.Родитель)        КонецЕсли; КонецФункции [/С]

дык я о том как урезать. Честно говоря с такой задачей не сталкивался, потому типовые не смотрел. Первое что в голову пришло. Хотя по логике цикл будет правильнее - память не будет кушать. Надо будет взять на вооружение. Мало ли когда приспичит.

+ а если с циклом и без запросу - то наверное так будет оптимально:

всем спасибо за мысли и предложения... ввел ограничение на кол-во уровней, вернее приблизительно прикинул максимальное число уровней (взял 10, т.к. сомневаюсь что будет больше, а если и будет, то можно быстро подправить) получилось следующее: ВЫБРАТЬ    ИЗ

запрос не оптимизирован, но это уже другой вопрос для другой ветки :-)

Не то слово. и в ИНАЧЕ наверное все таки стоит запихать пустую ссылку, а не ссылку на самого себя.

Зачем вложенный запрос непонятно.   Выбор Когда Спр.Родитель = ЗНАЧЕНИЕ(Справочник.ПодразделенияОрганизаций.ПустаяСсылка) Тогда     Спр.Ссылка Когда Спр.Родитель.Родитель = ЗНАЧЕНИЕ(Справочник.ПодразделенияОрганизаций.ПустаяСсылка) Тогда .... ИЗ Справочник.Подразделения КАК Спр

О! У меня такая же проблема!

, благодарю за уменые мысли ;) на данном этапе думаю остановиться, дальше оптимизировать не вижу смысла:

а где иначе с пустым родителем?

+ вернее 1 - когда должно возвращать не ссылку на само себя, а пустую ссылку.

разве здесь не обработается эта ситуация:

дык о чем и речь. Родителя нет и возвращается ссылка на сам элемент  вместо пустого значения.

согласен =) просто у меня не может быть ситуации, когда пустой родитель...в пусть таком случае пусть ссылается сам на себя