ПОДОБНО в запросах работает с конкретными текстовыми операндами. а можно ли переменную сравнить с массивом масок, т.е. логически объединить
Мойобъект.Мойреквизит В (&МассивЗначений)
Мойобъект.Мойреквизит ПОДОБНО "%" + &ОдноЗначение + "%"

и получить типа Мойобъект.Мойреквизит ПОДОБНО В (&МассивМасокЗначений)? Этот запрос хочется вставить как произвольный в динамический список и чтобы все летало.

Нельзя.

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

Меняйте логику хранения данных

невозможно...

(2) Если тысячами, то надо через равно. Через подобно летать не будет, по-любому.

(4) Не верю.

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

(6) Да-да. Именно в связь таблиц и пихаю...

(0) https://www.youtube.com/watch?v=WSGW4dQTncg
(4) уволить тех кто говорит "невозможно". сделать нормально.

(6) Так делать не рекомендуется.
https://its.1c.ru/db/v8std/content/726/hdoc
При использовании в тексте запроса оператора ПОДОБНО допустимо использовать только константные строковые литералы или параметры запроса. Запрещается формировать строку шаблона при помощи вычислений, использовать конкатенацию строк средствами языка запросов. Например, допустимо.

Реквизит ПОДОБНО "123%"

Недопустимо:

Реквизит ПОДОБНО "123" + "%"
Реквизит ПОДОБНО Таблица.Шаблон

Запросы, в которых управляющие символы шаблона оператора ПОДОБНО находятся в полях запроса или в вычисляемых выражениях, по-разному интерпретируются на различных СУБД. Запрос, успешно выполняющийся, например, при работе с файловой базой, может возвращать неверные результаты при работе в режиме клиент-сервера. Подобные выражения необходимо переформулировать.
Данное требование продиктовано необходимостью переносимости прикладных решений на различные СУБД.

(9) Мы же не знаем все подноготной ТС. "Данное требование продиктовано необходимостью переносимости прикладных решений на различные СУБД." ->так может не стоит такая задача обозримом будущем. Может у него вообще разовая задачка, по выданной табличке масок проанализировать и выдать результат.

(10) разовая задачка с помещением в динамический список? нестыковочка.

(11) Тут с самого начала нестыковочка, летает и ПОДОБНО редко когда сочетаются)

(10) Не спорю. Возможно конечно. Но всё же.
Когда 1С пишет, что один и тот же запрос может выдавать разные результаты в разных СУБД, это фактически следует понимать, что запрос может выдать вообще всё что угодно в любой момент. После обновления версии платформы, обновления версии СУБД, обновления статистики или индексов в СУБД, на разных копиях одной базы и т.д.

Для нормальной работы автору всё равно надо менять либо требования, либо логику хранения данных.
А подробностей он не рассказывает. Может в его случае вообще имеет смысл в сторону полнотекстового поиска данных копать по строке "шаблон1 ИЛИ шаблон2 ИЛИ ... ИЛИ шаблонN", получать список поиска и пихать в качестве параметра в свой запрос. Вряд ли конечно, но мы ж не знаем всех нюансов и механики работы пользователей с его динамическим списком. Как часто меняются шаблоны поиска, сколько этих шаблонов (1,10,100,1000)?...

(0) Нет уж, так легко ты от запроса в цикле не избавишься

(11,12) Задача разовая, пользоваться будут часто, постоянно. Поэтому надо летать ибо потом опять придут что работает медленно. Надо уже сейчас исчерпать предел возможностей.

(13) Шаблон поиска - это трекер почты. Их каждый раз забивают руками. Списком в многострочное текстовое поле. А потом массивом (как сейчас) подсовывают в запрос и сравнивают точно с Регистром накопления (реквизитом). А надо подобно искать по неполному трекеру (по первым символам). Любая строчка может быть или полным трекером, или неполным, т.е. шаблоном.

Полный трекер-частный случай шаблона. Поэтому дальше обсуждаем шаблоны.

Просто все.

+(16) Т,е. прошел трекер через регистр или нет.

(0)
выбрать ... где х подобно "%шабл1%"
объединить
выбрать ... где х подобно "%шабл2%"
объединить
...
объединить
выбрать ... где х подобно "%шаблN%"

тот же самый ИЛИ, но только производительный/оптимизированный

(19)
>производительный/оптимизированный
это за счет чего?

из теории оптимизации запросов
вместо "... где а или б или с" оптимальней будет
...где а ...объединить ...где б ...объединить ...где с

(20) +на практике делал замеры в таких (21) запросах в RLS - действительно быстрее

(21)
>из теории оптимизации запросов
что-то не встречал такого...

если уж считаешь, что ИЛИ без оптимизации работает, тогда ВЫБОР КОГДА...

(22)
странно.

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

В общем если через равно из регистра за 3 секунды выбирает для 400 масок по трем полям Трекер.
А через подобно для 400 масок выбирает более 500 секунд.
Но с ростом регистра вырастут и тормоза.
Хотя тут регистр уже за несколько лет.

(21) Тоже чего-то слышал, сейчас пробую... Три Подобных на каждый реквизит отдельно и Объединить

(16) >Шаблон поиска - это трекер почты. Их каждый раз забивают руками. Списком в многострочное текстовое поле. А потом массивом (как сейчас) подсовывают в запрос и сравнивают точно с Регистром накопления (реквизитом). А надо подобно искать по неполному трекеру (по первым символам)

Меняй хранение
Делать отдельную табличку для шаблонов-трекеров и не в общее многострочное а привязывай ТЧ

(21) По 30 шаблонам 20 сек любым способом.

(15) >Задача разовая, пользоваться будут часто, постоянно.

В цитаты!

(16) Чем стандартный поиск в ДС не устраивает?

(21) нужно проверять на конкретной СУБД, а также на конкретной версии, а также на конкретных данных

(30) >> Чем стандартный поиск в ДС не устраивает?

Если я правильно понял автора, то у него шаблон не один, а несколько.
Стандартный поиск в ДС позволяет искать только по одному шаблону.

(32) Нашел, ткнул какую-нибудь галку, информация сохранилась, ищешь следующий.

Зачем делать это нечеткое сопоставление постоянно?

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

(16) Так в итоге. Сколько шаблонов одновременно вводится пользователем? 400 или 30?
Пробовали применять полнотекстовый поиск?
Если максимальное количество шаблонов (слов в запросе полнотекстового поиска) не превышает 32, длина строки поиска укладывается в 1000 символов, и при нечетком поиске результат укладывается в 300 слов, то можно попробовать.
Создать список поиска. В привилегированном режиме и без получения представления и описания (для ускорения). Если все результаты поиска будут получены (СлишкомМногоРезультатов()=Ложь), то, обойдя этот список, сформировать массив который подсунуть в качестве параметра для отбора.

ОФФ. Уже второй день обсуждения, а задача так и остаётся мутной и непонятной.
Для оперативной работы копать регистр, в котором лежат данные за несколько лет, - очень странная затея.
В подобных случаях либо регистр периодически чистят от старых данных (сворачивают), либо разделяют данные на разные таблицы - с оперативными (рабочими) данными и с архивными данными. Может имеет смысл поле Трекер сделать не строкой,  а ссылочной сущностью (справочником, например), если один и тот же трекер в большом количестве записей регистра встречается. Поиск по относительно небольшому справочнику будет работать быстрее, чем по огромному регистру.

Короче вариантов масса. Но чтобы рассуждать о них надо знать больше подробностей.

а нельзя строку запроса сделать

Мойобъект.Мойреквизит ПОДОБНО "%" + &ОдноЗначение + "%" или Мойобъект.Мойреквизит ПОДОБНО "%" + &ОдноЗначение1 + "%" или Мойобъект.Мойреквизит ПОДОБНО "%" + &ОдноЗначение2 + "%"

?

(33) Вечность - это мутная река

(35) Выясняется, что не все шаблоны приблизительные, есть точные совпадения. Тогда надо сначала отфильтровать точные, если их 99%, то приблизительно искать только оставшиеся. Будем пробовать так.

(35) Выясняется, что не все шаблоны приблизительные, есть точные совпадения. Тогда надо сначала отфильтровать точные, если их 99%, то приблизительно искать только оставшиеся. Будем пробовать так.
откуда точная постановка если Люди Руками вносят Всякую Хрень?

(39) Как выглядят в реальности полные треки и массивы которые отправляются для поиска ?

Как угодно, заказчик до конца не знает. Сегодня так, завтра так..

(41) это звучит как вечное сопровождение, а не разовая задачка.

(41) >> Как угодно, заказчик до конца не знает. Сегодня так, завтра так.

Чтобы родить верное решение придётся требовать от заказчика сузить и конкретизировать требования.
В любом другом случае оптимального решения получить не получится. Будет либо работать медленно (если пытаться наваять что-то универсальное "на все случаи жизни"), либо неудобно для пользователя (если загнать его в слишком узкие рамки).
Возможно вообще придётся предусмотреть несколько способов/вариантов - на разные случаи - когда надо найти данные по чёткому совпадения, по нечёткому, по одному трекеру, по массиву трекеров.

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

(42) Да...

Решение такое - сначала ищем полные соответствия исходным шаблонам (через =).
Потом ищем типовые ошибки пользователя: исходный шаблон плюс разные часто забываемые префиксы на полное соответствие (через =).
Потом отбираем какие шаблоны найти не удалось.
Дальше пускаем в ход ПОДОБНО как исходным шаблоном, так и с разными префиксами... потом ОБЪЕДИНИТЬ эту трагедию и выдать на экран что нашлось, а где руки совсем мимо клавиш пошли.
На большее заказчик все равно не исхитрится.
Надеемся что специально всякую кривизну забивать не будут. У пряморуких сотрудников поиски будут идти быстрее и выработка будет больше.
Как-то так...

На любую непонятную задачу можно придумать ещё более непонятный алгоритм.

(46) Оно у тебя исполняться будет так же долго как описано.
Прими парадигму - меньше 3х символов - не ищем и разорви трек.

(48) Нет, секунд 7 отрабатывает при условии что штук 10 через подобно ищутся, а остальные ошибки "частые".
Кроме того, систему можно сделать самообучающейся если ей сделать РС. Частые ошибки и научить делать синтаксический разбор "что на самом деле что".
Просто нужна доп форма где система будет помнить какой юзер какие ошибки делал и в начале дня будет требовать ответить что он искал на самом деле.
Этот же лог можно старшему менеджеру показывать.

(49) ты на пустом месте изобрёл ещё одну АРМ.

+(50) тогда как было проще выкинуть первую и сделать нормально.

Оплата пропорционально усилиям. Поддерживать смогу только я и ещё один парень с Дальнего Востока.