НайтиПоНаименованию() - принцип выбора найденного элемента из нескольких #722374

Читал чужой код и встретил конструкцию с функцией НайтиПоНаименованию и стало интересно как она находит элементы. Вот, к примеру такая ситуация. справочник контрагенты, в нем есть два элемента Иванов Федор и Иванов Иван. элемент с наименованием Иванов Федор помечен на удаление, а Иванов Иван нет, у Феди порядковый номер 002, а Ваня идет с номером 001. Код у нас такой: Если смотреть отладчик получаем найденный элемент Иванов Федор, однако, он у нас идет за номером 002 и помечен на удаление. В СП нам сказано: Примечание: Если существует несколько элементов с указанным наименованием, то будет найден только один из них. Получается, что функция проходит по списку, который упорядочен по убыванию, так шоль? З.ы. забыл указать платформа 8.2.13.219

Порядок не определён. Как БН на душу положит

наверно, физическое расположение элементов в базе играет роль.

по УИД что там у них?

да даже если по строковому представлению уид - все равно не гарантировано, раз не описано в документации

гарантировать легко, а именно посмотреть запрос формируемый в СКЛ. В общем по гуиду

т.е по гуиду? т.е. строится список где упорядочивание идет по гуиду? а упорядочивание как - по возрастанию или убыванию?

Возрастание

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

мастер Йода, это вы?)))) вопрос в том как именно происходит поиск соответствия. проверил предложение Ник второй и hhhh из сообщений ,, похоже на правду!

Мда, ты считаешь кластерного индекса нет? А теперь вспоминай какой кластерный индекс используется у Справочника. Перед тем что то писать советую немного мозг включать.

похоже всё-таки индексом на наименование эта команда пользуется. ТО есть не тупо подряд перебирает все наименования.

Видимо, вы имеете особенность его (мозг) выключать. Поздравляю! Осталось только научиться читать. Успехов!

exec sp_executesql N'SELECT T1._IDRRef FROM _Reference62 T1 WITH(NOLOCK) WHERE T1._Description LIKE ESCAPE ''''', N' nvarchar(4000)', N'Иванов%'

а если СправочникМенеджер сначала посмотрит кеш, а не станет запрос делать?

Вот вот.

ну это уже тонкости.

Спасибо за поздравления. Действительно люблю мозг включать.

от которых ответ меняется с "да" на "хз" ) как и описано в СП

понятно, что статистика и кеш могут повлиять на результат. Но общий посыл от этого не меняется )

Тогда отпадёт необходимость заниматься так фигнёй как установка пометок на удаление и изменение кодов элементов ради получения неочевидных результатов.

[понятно, что статистика и кеш могут повлиять на результат.] ответ хз [Но общий посыл от этого не меняется )] ответ да. ОтветРезультат(хз, да) = почтивсегдада, в конце и правда "дада", Вы победили

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

+1 )) Запросы для этого придумали.

Еще заметил, что НайтиПоНаименованию частенько используют именно семерочники, старички )))

потому что им больше программить приходится, в отличие от 8-ков расставлятелей галочек. . а хотелки персонала обильны отсутсвием логики и упорядочивания. Если на каждую хотелку делать настройку-константу - то никто в этих настройках кроме того же программиста разбираться не будет. так что совершенно пофиг - НнайтиПонаименованию или иначе. . тем более как правило найтипонаименованию - это самописки/костыли. и если по наименованию найдет -то ок, не найдет - или сломается сразу или никто ничего не заметит

Это были бурные овации пейсателям типовых? Настолько круто написано,что осталось только галочки расставлять? Где такое можно купить?

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

Напиши в общем модуле процедуру и вызывай ее в одну строку.

Ну и жутко не терплю прыгать по куче модулей, получается мало того, что надо разобраться в трех-четырех тысячах строчек кода объекта, так еще и несколько тысченок строк из других модулей. К тому же стараюсь делать, чтобы отчеты и обработки были самодостаточны без изменения конфы

+ ну и, если эту процедуру написала сама 1с, почему бы ее и не использовать

Llllet's get ready for rrrrrrrrumble!

я еще 77 сталкивался с подобным, когда В файловой версии находился один элемент справочника, а в скл  версии находился другой эдемент справочника. На одной и той же базе...

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

Теперь идём в справочник ЕдиницыИзмерения и...

а там  отбор по владельцу)))

чо?? Наличие элементов с одинаковым намениваем - нонсенс?? М да..

факт остается фактом. выборка была различной в зависимости от варианта системы.

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

А ты никогда не боролся с вариантом, когда в справочнике Контрагенты или Номенклатура были задвоенные наименования? Я боролся, и очень не хочу развлекаться с этим снова... И в справочнике сотрудники тоже надо как-то сотров различать иначе получится тот же геморрой, какой у меня сейчас в одной доставшейся базе, когда пять одинаковых имен, но работать они должны в разных фирмах, называется угадай, какой где...

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

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

ленивые разработчики всегда создавали проблемы..

Ну и еще, ФИО одинаковые давать без проблем, но точно также без проблем и написать в наименовании сотрудника, нечто вроде: Иванов Иван Иванович (Фирма Спектр)... Тогда не у кого не будет вопросов как с этим Ивановым работать...

уууу.. к Кодду, Кодду)))

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

+1 соглашусь. И это сделано в типовых, например ЗУП, спр.сотрудники. При многофирменном учете очень удобно.

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

а в упп сотрудников можно выбирать как из всего списка, так и по организациям/подразделениям.. и за "иван иваныч(спектр", будь я иванычем - морду бил бы программисту))

Давай не будем о теории, заведи разных Иван Иванычей Ивановых на девяти разных фирмах и дай бухам с ними поработать, а после того, как будешь за ними вычищать уже можешь сказать все, что ты думаешь о "парадигме"...

+ Зайди ка в типовую демку УПП и с обнаружишь, что даже в типовой демке наименования сотров идут: Краснова Венера Петровна (осн.) Ну и после этого, можешь подойти ко входу в 1С, когда они рабочий день заканчивают, и по морде... и по морде...

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

в 1с тоже не все читали теорию баз данных.. хотя их знания про теорию - это уид и ссылка... почти ключи для типа/значения типа..

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

контрагентов  я ищу по инн. Номенклатуру вводом по строке, а не через f3 - потому что знаю, что будут дубли..

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

Ну и очень полезно поискать в пользовательском режиме номенклатуру по уиду... И что ты вводишь в строке, если наименований одинаковых с пяток будет? Уверяю тебя тем же бухам будет многократно понятней, если они будут видеть Единственную возможность ввода одного имени, а не пять элементов с разными кодами...

Объясни в базе, где ИНН заполнено дай Бог только у двадцати процентов, тоже прояснение будет, к тому же ИНН без проблем может дублироваться, тогда уж и про КПП говорить надо...

Друг, я буду решать проблему дублей "вообще" через инн в  конфах 1с..наименованием точно не буду пользоваться.. в "частности" -  решение уникальности через наименование только если количество контрагентов десятки, ну может сотня другая..откланиваюсь..

Да я разве против? Решай как тебе вздумается. Я уже решил. Причем не в одной фирме, а в нескольких десятках. Работает... Вот только не забывай, что справочник Контрагентов - это один из большого количества справочников. Есть еще ОС (сейчас в одной из моих фирм ОС порядка пяти тысяч наименований), Номенклатура, Статьи затрат (иногда их очень много), Оборудование, и много чего еще, где ИНН-ом и не пахнет...

найтипонаименованию - зло даже не из-за того что наименование не тру использовать в поиске, а из-за того заставляет лишний раз насиловать сервер. ОСТАВЬТЕ сервер в покое, что он Вам плохое сделал?

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

1С и так оочень оптимизированная. Для разовых обработок не важно, можно и запросы в цикле... но частенько встречаю такие вещи в обработках проведения и подобное.

Очень. Где-то встречал сравнение скорости 1С и какой-то версии ФоксПро, разница в скорости раз в сто была не в пользу 1С :-( Да и запросы в цикле в типовых ну очень часто встречаются :-(

сегодня в очередной раз смотрел правила обмена.. от меня (с моего подрядчика) - везде найтипонаименовмнию...

Лучше извлекать запросом - а то мало ли - два наименования, помеченные на удаление и так далее. Выражение LIKE с % позволяет находить нечеткие соответствия.

+ ,спасибо КЭП. :)

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