Есть таблица значений, в ней есть колонка Поставшик.
В колонке Поставщик 150 одинаковых поставщиков и несколько отличающихся.
В запрос надо передать списов поставщиков в условие среза регистра сведений
Поставщик В (&МассивПоставщиков)

Вопрос:
1. есть ли смысл делать так:
ТЗ.Свернуть("Поставщик");
Запрос.УстановитьПараметр(ТЗ.ВыгрузитьКолонку("Поставщик"));

2. или достаточно так
Запрос.УстановитьПараметр(ТЗ.ВыгрузитьКолонку("Поставщик"));

Как вы считаете и почему так думаете?

Вариант 1

(1) А почему так думаете?

(0) смысла нет, можешь еще в цикле миллиард строковых GUIDов туда добавить, всё равно результат один будет

(3) А почему так думаете? Обосновать можете?

(4) почему результат запроса будет тот же?

вариант (1). Результат будет один и тот же. Но первый, имхо, быстрее за счет того что в параметре будет меньше строк, соответственно меньший перебор. А может и по времени одинаково)
Сделайте замер и узнаете.

(5) Результат то будет одним и тем же, а как по производительности?

тут над мерить, как Свернуть() работает...

Меньше констант в sql передавать.

(8) Одномоментно. Лучше его "Свернуть" на Клиенте, причем.

(9) А константы в скуле через ИЛИ будут сравниваться?

Твой массив в скуль-запросе будет выглядеть типа
ГДЕ (Параметр1,Параметр2,Параметр3...

Если свернешь - меньше параметров будет в запросе фигурировать

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

(0) Почему то люди думают что SQL это какой-то волшебный ящик, а он как все, переборчиком

ну то что скулю будет легче, это 100 пудов

(14)
Вопрос во времени - что быстрее - скуль сравнит результат с каждым одинаковым значением параметра, или же быстрее свернуть заранее результат средствами 1С

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

а если 1С крутится ну умирающем пентиум 2, а СУБД на супермегабыстром сервере...

>>В колонке Поставщик 150 одинаковых поставщиков и несколько отличающихся.

Я бы цикл сделал по таблице. 150+ строк - это вообще ни о чём

(18) Простой перебор отработает "в лёт" даже на умирающем андроиде.

(20) в таблицах из выборки по 5 записей, а в параметре 5 миллиардов

*(21) в таблице из параметра

(17) а почему вы считаете, что функция по удалению дублей массива не в скуле выполняться будет?

(23) Потому, что я ЛИЧНО выполню её на клиенте.
Использую готовую функцию из БСП: ВыгрузитьКолонку(КоллекцияСтрок, ИмяКолонки, ТолькоУникальныеЗначения)
Потому что с гораздо большей вероятностью узким местом станет клиент-серверное взаимодействие на слабых каналах, чем тормоза на большом количестве итераций даже на самом слабом железе.

(24) + Хотя... В сабже речь либо о сервере, либо о тонком клиенте... Все равно так бы сделал. Ежели чо - рефакторить проще будет.

(25) + Тьфу, о толстом клиенте.

(24) Спасибо, это многое объясняет. Но почему вы думаете, что когда массив будет передаваться с клиента на сервер, то скуль тут участвовать не будет?

(27) Не понимаю вопроса. Будет участвовать. В качестве принимающей стороны. И что?

(24) и почему вы считаете, что время, затраченное на передачу массива с клиента на сервер принесет вам выигрыш?

(27)
Как бы пробовать / делать замеры не пробовал ?

Свертка ТЗ , ее полный перебор, заполнение прим размерах до нескольких тыщ - доли сек.
Запросы - намного больше (в среднем)
Чего здесь на форуме обсуждать когда отладчик есть ?

(24) +100500!

Клиентов много, серверов 1С меньше, сервер SQL - вообще один.

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

Или я не прав?

(33) а причем тут вообще клиент?

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

(35) ТЗ.Свернуть рулит на Толстом,
перебор - на Тонком

(34)
Возьми и померяй. Имхается шо не

(36) На сервере тоже рулит )

(29) Минимизация количества и объема данных клиент-серверных взаимодействий - разумная стратегия при реализации любых клиент-серверных приложений. Пихать на сервер даже элементарную арифметику и несложные переборы ценой увеличения трафика - глупость. Рациональнее тогда уж терминальный сервер юзать.

Вообще, если есть вероятность, что в ТЗ может содержаться приличное количество значений, то лучше использовать временную таблицу. Иначе запросто можно словить ошибку СУБД.
Кстати, если кому интересно, 1цэ не передаёт дублирующиеся значения в СУБД, но количество параметров в тексте запроса при этом соответствует количеству элементов массива.
Т.е. примерно так:
... f1 in (@p1, @p2, @p1, @p1,...@p1)

(39) Ваше мнение резко отличается от мнения разработчиков типовых конфигураций на управляемых формах )

(40) "1цэ не передаёт дублирующиеся значения в СУБД"
Где вы взяли это знание?

(42)
Это можно наблюдать через профайлер или в ТЖ.

И кстати от количества значений в конструкции

f1 in (@p1, @p2, @p1, @p1,...@p1)

зависит то, какой план запроса построит скуль, если поле индексированное.

Для небольшого количества будет index seek с условиями Поле =p1 or Поле = p2 и т. д. , для большого будет через inner join со служебной таблицей в которую будут загружены значения.

(44)+ Правда не пробовал вариант, когда много повторяющихся значений.

(43) то есть, п.1 в (0) ТЗ.Свернуть(Колонка) делать не нужно? Одинес сама уберет дубли и передаст скулю?

(40) "1цэ не передаёт дублирующиеся значения в СУБД, но количество параметров в тексте запроса при этом соответствует количеству элементов массива"

Ты взорвал мой мозг.

(47) + Вроде идею понял, но это какой-то полный бред. Никакой логики.

(47) Наверное имелось ввиду, что для уникальных было бы

p1 = a
p2 = b
p3 = c
p4 = d
f1 in (@p1, @p2, @p3, @p4,...@pn)

а передается так

p1 = a
p2 = b

f1 in (@p1, @p2, @p1, @p1,...@p1)

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

(49)+ Для

exec sp_executesql N'
...
f1 in (@p1, @p2, @p1, @p1,...@p1)
...
',N'@p1,@p2','a','b'

(51)+ Не уверен что именно так выполняется, но примерный смысл понятен.

(49) Да я так и понял. Только какой в этом смысл? Если 1С УЖЕ заморочилась со сверткой значений в параметрах, нафига оставлять избыточность в тексте запроса?
"Не верю!". Это ж даже сложнее реализовать.

Хотя... Может такое быть. Они могут просто ВСЕ параметры по единому алгоритму "сворачивать".

Есть еще такая вещь - как параллельные вычисления.
Если клиенты хотя бы уровня Core 2 - суммарная выч мощность клиентских - в 50-100 раз больше, чем самого мощного сервера. Причем все распараллелено.
Поэтому удивляюсь желанию некоторых все пихать на сервер.
Также удивляюсь при "нормальном" клиент сервере стремлении запихнуть еще терминал (видимо уши от 7.7)

(54) + Трафик от сервера приложений к субд это, конечно, минимизирует. Но "хвосты" в запросе - тоже ничего хорошего.
И наиболее критичный трафик - от клиента к серверу приложений.

(53) вопросы веры или неверия в доказательствах не нуждаются...

(55) Профессиональное деформирование 7.7

(55) Ну, терминал позволит централизованно предоставлять какую-то доп-инфраструктуру, кроме 1С. Да и тех же тонких клиентов проще поддерживать. Нормальный деплоймент тонкого клиента вон только в КОРП-версии сервера организовали.