можно ли запросом найти родителя первого уровня #426604

встала задачанайти у элемента родителя первого уровня. сделал и через рекурсию и через ПолноеНаименование. Очень интересно можно это сделать через запрос?

Нет

вряд ли.

Можно.

Например?

Смотря где нужно, если в условии запроса - то запросто, а вот группироку не слепишь... а так, на вот:

зачем запросом?

прямым запросом запросто можно..

Прямыс запросом всё, что угодно можо сделать :-)

Поделитесь Тоже пример бы?

Задача: Надо перебрать элементысправочника номенклатура и присвоить реквизиту значение(название) родителя верхнего уровня

а если ТОЛЬКО запросом без курсоров и udf/udp?

Можно. Вариантов несколько. Смотря где, как и зачем.

На 2005-м - можно.

Выбери нужного родителя на форме и в цикле присваивай всем элементам. Ничего искать ненужно.

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

Ну и что? Ты ж выберешь группу по порядку.

ну и что ? 2 выборки и привет.. первая по группам верхнего уровня, вторая по вложенным элементам этих групп и привет.

ну допустим элементнаходиться на 6 уровне как мне найти его родителя 1 уровня в запросе

Select From Дерево_Номенклатура Дерево Left Join спрНоменклатура Товары On Товары.ID = Дерево.PerentID Where Дерево.ID = @идТовар And Товары.УровеньИерархии = 1

Покажи определение вьюхи Номенклатура_Дерево?

Зачем тебе запрос?

Это не вьюха. Это таблица.

Для тех кто нечитает ЖКК - ПринадлежитГрупе, Использоватьродителя, ... Вариантов куча, но ты упорно флудишь вместо чтения мануала.

и триггером заполняется? Некошерно...

Мне просто стало интересно можно ли это сделать посредством запроса. какой же это флуд

Почему это некошерно? По моему, наоборот, - самое оно.

А по мне - так некошерно :-) Для 77 и вьюха сойдёт...

Зачем это вообще знать ? 2 выборки (вложенные друг в друга): первая по Группам самого верхнего уровня, вторая по вложенным элементам первой выборки.. всё.

Так все-таки - чем некошерно-то? И как ты себе представляешь такую вьюху? Если элемент справочника находтся на 6-ом уровне, в этой таблице будет 6 строк.

для общего развития. что в этом плохого

Некошерно лишними действиями при записи. А вьюха - например с полями родитель1 - родитель9...

см.

Эта избытычность данных и, соответственно, лишние действия скуля при записи элемента справочника - такие крохи по сравнению с тем, какой получаем выигрыш при построении отчетов... "А вьюха - например с полями родитель1 - родитель9" - можешь показать текст запроса? 9 связываний таблицы самомй с собой? Такое проходили. Тормоза не хилые.

за спасибо просто интересует а где флуд.

Скажем так - я бы такое применять не стал без специальных замеров.

Поверь, замеряли и тестировали. Зато, фильтр по группе выглядит как конфетка: Where  ID IN (Select ID From Дерево_Номенклатура Where ParentID = @идГруппы)

+ Хотя почему я написал "зато"?? Просто - фильтр выглядит как конфетка! :)

"Случаи разные бывают" (с)

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

если родитель первого уровня имеет некую смысловую нагрузку (ну например товары отсортированы по направлениям деятельности компании и это и есть группы первого уровня или, скажем, бренды и т.п.) - может имеет смысл добавить поле типа "бренд" или что там еще (и организовать отдельным справочником) и не парить себе мозг? решение оригинально... но может не стоит так усложнять? :) P.S. конечно если ставится задача находить постоянно родительские группы произвольного уровня для справочника с нежесткой структурой (в смысле элементы могут находиться на любом уровне и уровней этих много) - тогда триггеры конечно рулят...

См.

Самый популярный пример - отчет с фильтром по группе товаров, контрагентов. Чёт я не понимаю глубину твоей мысли :) Приведи пример?

я ж грю - каждый случай должен тестироваться на месте. У меня сейчас тут 1с даже к скл не подключается, ибо 2008, а кряки искать лень :-)

При реструктуризации Вашу таблицу одинце убьет. Вы утверждали, что можно одним запросом. Так вот можно ли?

а обычное ПринадлежитГруппе в данном случае не проще и быстрее? кстати, а зачем именно триггеры? т.е. почему не реализовать отдельным справочником? это удобнее будет в том смысле, что эска херит "инородные" объекты в ряде случаев.

не убьёт. НО при загрузке выгрузки не создаст.

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

я только что придумал, ишь какой ты быстрый :)

Тогда сначала подумай над программной записью объектов и тем, как не менять половину конфигурации :-)0

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

Перехвати штатно Элем.НОвый; Элемент.Записать; во внешней обработке :-)

"херит "инородные" объекты в ряде случаев" - в единственном случае. При восстановлении з бэкапа, сделанного 1С-кой. Но мы же не больные люди и делаем бэкапы скулем, а не 1С-кой, не так ли? Ну-ну. Чё-то моя 1С-ка не убивает :) "Вы утверждали, что можно одним запросом" - Я?

Ага, ага. А еще измени штатный механиз удаления помеченных объектов :)

убедил :) помнится romix выкладывал способ перехвата запросов платформы и подмены оных - есть поле для деятельности :) впрочем прав, мой вариант выйдет сложнее

перехват этих запросов называется "триггер" :-)

спасибо, теперь я знаю, что такое триггер :) я о перехвате на уровне именно платформы, ну допустим реализация фильтров по необщему журналу и т.п., т.е. без вмешательства в скуль, а именно расширение функционала стандартных объектов.

Патчинг платформы? Или какие-то классы? но как классы могут перехватить данные из обработки, которая про них не знает?

Нафиг-нафиг... Уж лучше свой журнал нарисовать на табличном поле. Заодно и возможностей больше будет.

по-моему там идет перехват вызовов посредством хуков почему лучше? ну или чем :)

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

+ Да и внешний вид получишь гораздо более эстетичный. Глянь, как у нас журнал выглядит: п. 3.

табличное поле - родственник ТЗ, так? а со скоростью вывода траблов не будет (на большом числе доков)? кстати по сабжу: а вот нижеприведенную методику нельзя применить? здесь: sc21 - некий справочник (игрался на нем), '03117' - код некоего элемента на n-ном уровне иерархии запрос выводит в табличной форме по восходящей всю иерархию, т.е. в последней строке - искомое почему так не сделать? (не спор ради спора, а именно исследовательский интерес)

потому что 77 не работает с 2005м (с) :-)

+62 а пример для журнала есть (глянуть код, а то не все понятно), самый простой (т.е. не имеющий никакой коммерческой ценности)? :)

хз... как она у меня работает... :))

+65 т.е. не аргумент :)

Адрес конторы опубликуй, чтобы к тебе выехали :-))

Можно заставить её работать

это вообщем-то не нарушение, ибо нелицензией я не занимаюсь, а заставить работать под 2005-м скулем - вообщем-то не нарушает ничьих прав, уже обсуждали здесь :)

В базе 14.5 лямов документов. Полет нормальный. На запрос завтра гляну - сейчас и некогда и башка уже не варит :( Неа, нету. По многим классам раскидан. Есть пример справочника, в разделе "Скачать". А что именно не понятно?

.2 с какой стороны подходить к табличному полю :) я просто не юзал его как-то вот так вот получилось...

Качни Там справочник на таблином поле. Только это не самы простой пример...

ниче, попробую разобраться, спасибо :)

+62 пример вывода всех "детишек" выбранного родителя (в данном случае, подставляется код такого родителя, что непринципиально, конечно) результат действия такого запроса можно юзать например через выгрузку во временную таблицу и проверки в другом запросе на вхождение в эту таблицу айдишника элемента:

+74 ессно кроме поля ID нам ничего не надо, просто для наглядности оставил код и наименование может кому-нить поможет :)

А зачем в каждом отчете зачтавлять скуль это делать? Если это можно сделать 1 раз и пользоваться?

например уже есть боевая база с куче

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

по идее, работать должно довольно быстро, можно сравнить по замерам, что лучше

А какая разница, когда делать триггеры и доп таблицы?

я может чето путаю, но разве триггер "задним числом" отработает? триггеры же у тебя на запись и изменения стоят, так? ну а если все уже записано? конечно можно заполнить таблицу однажды и потом она будет дополняться действиями триггеров... мне больше по душе вариант без "левых" объектов в базе (насколько это возможно и допустимо и не в ущерб производительности)

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

+82 кстати: я таки пытаюсь ответить на сабжевый вопрос :) по условию требуется одним запросом найти родителя первого уровня, по сути раскрутить все дерево - решение приведено и именно одним запросом без доп. действий :)

Создал триггер и в функции перехода на новую версию прописал апдэйт каждого элемента справочника. Таблица заполнена. Твой вариант, скорее всего, по скорости проиграет. А с таблицей и множественный фильтра на ура делается:

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

.2 хотел уточнить: в ту хитрую таблицу ты проставляешь только родителей первого уровня для всех элементов или я недопонял? т.е. если у нас ID1 - ID2 - ID3 (где второй и третий - группы, расположены матрешкой) - что записывается в таблицу-дерево?

с HierarchyId не работал?

Все вышестоящие родители. Неа. Надо будет глянуть на досуге.

.1 по типу полного кода?

Нет. Элемент и его родитель, Элемент и родитель родителя и т.д.