Не хватает понимания чем принципиально отличается "отбор" от "параметров", киньте ссылкой или объясните на пальцах, плиз.
Спасибо!
---
Основная идея отличия параметров, участвующих в условиях в запросе СКД и отборов в месте их исполнения. Запрос, выполняется на SQL сервере, соответственно и параметры влияют через условия запроса на его выполнение, а вот отбор уже фильтрует готовый результат выполнения запроса на уровне сервера предприятия. Соответственно вывода два: задание условий отбора на уровне запроса минимизирует трафик между SQL и сервером предприятия, ну и, ИМХО, думаю алгоритмы фильтрации результатов на уровне SQL серверов (даже если оно постргес или IBM) сильно эффективнее фильтрации на уровне сервера предприятия.
 В случае файловой базы различия конечно поменьше и менее понятны: во первых, в теории, отбор по условиям в запросе должен приводить к частичному, а не полному считыванию набора данных из БД, а вот отбор по результатам запроса сначала отбирает все подряд, а уже поверх полного результат натягивает фильтр.
---
Есть предположение что параметр передает в запрос собственно значение параметра, а отбор передает в запрос результат сравнения, т.е. результат сравнения может быть либо "да" либо "нет", а вот параметр.... что с параметром, не понятно...
---
Параметры ты должен указывать всегда, а отбор СКД подставляет в запрос, только если он включен в настройках. Причем, СКД сама "понимает" куда лучше поставить отбор: в конструкцию "ГДЕ" или в виртуальные параметры таблицы.
Когда ты указываешь параметры в запросе, то можешь поставить только один вид сравнения "=" или "<>" или "В" итд., а в отборе пользователь может устанавливать любые виды отбора.

На http://spec8.ru/ есть бесплатные видеоуроки по СКД. Очень познавательно, должен сказать. Так кстати этот вопрос в одном из уроков разбирается.
---
Acort, Когда ты указываешь параметры в запросе, то можешь поставить только один вид сравнения "=" или "<>" или "В" итд., а в отборе пользователь может устанавливать любые виды отбора.
этому вас на http://spec8.ru/ научили?
---
tango,
Фарит лично принимал....
---
Отбор используется для установки
условий фильтрации элементов в наборах записей.

Значения параметров могут
использоваться в выражениях
языка запросов
---
Параметр ели задаешь в запросе то он должен быть указан обязательно, а отбор по желанию.
---
Параметры в СКД тоже могут быть необязательными, для этого существует конструкция в виде фигурных скобок, например {(&НачалоПериода)} и .т.п.
---
Поручик,
Параметр если задаешь в запросе
Параметры в СКД тоже могут быть необязательными

Если необходимо жестко задать значение (получить остатки по контрагенту какуму нить...) и поместить там в вт скажем,
а потом весь дальнейший запрос строится на основании этой вт уже.
Тогда контрагент параметр.
---
Akuji, Если необходимо жестко задать значение
Что значит жестко? Жестко это прописать прямо в запросе ссылку на конкретный объект, а если есть параметр то это уже не жестко :)
---
Ок. Может кто-нибудь привести примеры ситуаций когда какую-то задачу не возможно решить отбором/параметром но можно параметром/отбором?
---
Win98, ну вы бы хоть вознагражденье объявили, коллега
---
tango, можно :)

PS. Только я не знаю что с этими $m делать?
---
Сообщение было скрыто модератором.
---
Отбор - условия фильтрации, а параметры в основном используются в запросе, отбор как может быть так и его может не быть
---
DragonAgo, Ок. Чем будет отличаться отбор по дате от параметра(ов) с датой?
---
При параметре у тебя будет выборка, например, в 1000 записей, а при отборе все существующие записи таблицы, из которых в свою очередь выведутся в табличное поле нужные 1000, согласно отбору. Разница во времени формирования выборки может отличаться в разы, а то и на порядок.
---
mymyka, так, теплее, параметр "работает" в формировании таблицы, а отбор в ее отображении? Я правильно понял?
---
в (19) все популярно расписано.
---
Win98, в (3) что-то другое было написано?
---
tango,
Отбор используется для установки условий фильтрации элементов в наборах записей.

Значения параметров могут использоваться в выражениях языка запросов

и

параметр "работает" в формировании таблицы, а отбор в ее отображении?

Не уверен что вторая фраза тождественна первой...
---
Win98, ваша проблема
---
mymyka,
а при отборе все существующие записи таблицы, из которых в свою очередь выведутся в табличное поле нужные 1000, согласно отбору
это в случае если отбор будет через "ГДЕ",
а если задан в параметрах таблицы регистра скажем то результат уже будет содержать только таблицу после отбора.

"Жестко" значит что условие должно обязательно быть, пусть оно и задается в пользовательском режиме... но быть.
Либо один контрагент в моем примере, либо их список.
---
Это называется не отбор, а параметры виртуальной таблицы
(28) Например потому, что условия такого отбора можно и придется менять динамически. Рано или поздно пользователь попросит вывести НЕ в списке, или В ГРУППЕ(В ИЕРАРХИИ) и т.д. В случае параметра придется переписывать запрос, в случае отбора лишь изменить поле в настройках. Другое дело, что разница во времени формирования отчета по ВСЕМ реализациям по ВСЕМ контрагентам будет существенна.
(29) Это скд, в скд запрос всегда формируется заново )
---
mymyka,
Рано или поздно пользователь попросит вывести НЕ в списке, или В ГРУППЕ(В ИЕРАРХИИ) и т.д.
А как он еще может попросить? Например надо выбрать не элементы группы справочника, а саму группу? Какие данные можно захотеть как-то по другому?
---
Я немножко не про это. В параметрах мы явно указываем тип сравнения, равно/не равно/В(списке)/В ИЕРАРХИИ/ССЫЛКА/МЕЖДУ/ПОДОБНО...вроде все. Предположим по умолчанию параметр стоит с условием
Где РТиУ.Контрагент В(&СписокКонтрагентов).
Если пользователь попросит вывести реализации по любому другому условию, например НЕ в списке, что ты будешь делать?менять запрос? А в случае отбора сам пользователь может поменять тип условия и все. В параметры нужно вносить те условия, тип которых точно не будет меняться при любых условиях запроса, например Начало и Конец периода, вид РТиУ, организация и прочее.
---
mymyka, в общем согласен, но ведь и отбор можно вести по параметру. СКД этого не запрещает :) Т.е. параметр устанавливаем в "общее" значение (забираем всех контрагентов), а в отборе указываем НЕ равно/в группе/в списке :).
---
Win98, несколько раз похвалил mymyka, а деньги так и не отдаешь хотя чувак вроде все доступно объяснил, складывается впечатление что жмешь обещанные $m)))
---
m-serg74, да чего их жать? Да и списаны они уже с меня. Сейчас для меня бОльшая проблема - проблема выбрать. Изначально топик балтологический так что "награждать" тут трудно, особенно когда надо наградить одного.
Подожду до понедельника, в понедельник выдам два "вознаграждения", то что объявлено, и за второе место.
---
Win98, вопрос не в самих деньгах а в принципе... Вам понятно стало или нет, если понятно, то благодаря кому? вроде ответ очевиден...
---
m-serg74, смысл "небыстрой" выдачи приза в надежде что еще кто-нибудь заглянет и таки расскажет еще что-нибудь дельное.

PS. Надеюсь топик интересен не только мне?
---
Основная идея отличия параметров, участвующих в условиях в запросе СКД и отборов в месте их исполнения. Запрос, выполняется на SQL сервере, соответственно и параметры влияют через условия запроса на его выполнение, а вот отбор уже фильтрует готовый результат выполнения запроса на уровне сервера предприятия. Соответственно вывода два: задание условий отбора на уровне запроса минимизирует трафик между SQL и сервером предприятия, ну и, ИМХО, думаю алгоритмы фильтрации результатов на уровне SQL серверов (даже если оно постргес или IBM) сильно эффективнее фильтрации на уровне сервера предприятия.
 В случае файловой базы различия конечно поменьше и менее понятны: во первых, в теории, отбор по условиям в запросе должен приводить к частичному, а не полному считыванию набора данных из БД, а вот отбор по результатам запроса сначала отбирает все подряд, а уже поверх полного результат натягивает фильтр.
---
Sirin, сенкс, с местом исполнения разобрались. Осталось как-то поделить задачи (отыскать случаи) когда решение не возможно отбором или параметром. Каких случаев больше? Какие чаще встречаются?

PS. Пока Ваш ответ самый, на мой взгляд, толковый.
---
Win98, Обсуждение случаев использования отбора и параметров смысла не имеет. С точки зрения корректного использования СКД РАЗРАБОТЧИК всегда должен использовать параметры и, как следствие этого, условия отборов внутри запроса СКД, а вот если ПОЛЬЗОВАТЕЛЮ не хватает заложенных фильтров в параметрах - то он уже накладывает на готовый результат фильтр по отбору. Использование же отбора РАЗРАБОТЧИКОМ не есть гут: тут и излишняя нагрузка на сервер, и увеличение потока данных меджу звеньями архитектуры, ну и возможность нагадить пользователем в отборе (его-то в отличие от параметров от пользователя не спрятать).
---
Я конечно понимаю, что тема старая, но ведь это не правда — отборы накладываются на уровне СУБД.
---
и фильтр еще чем то от обора надо будет отличить)

нов итоге и получается что отбор это когда в запросе через "ГДЕ" мы отбираем данные.
Если про отбор в скд, то там скд сама вроде как определяем что можно запихноть в парамет, а что нет и наложить фильтр уже в итоговую выборку.
---
да тут все об одном)
---
В итоге есть ЗАПРОС, у него могут быть параметры (если их нет выводятся все данные)
если есть то проиходит в принципе всегда отбор либо по периоду выборки, либо по реквизиту.
Параметры: период, датаостатков, отбор по реквизиту, что там еще может быть...
Если отбор происходит в запросе он является параметром запроса.
Если отбор происходит после выборки это просто отбор/фильтр уже по выборке...

Отбор необходимо задавать по возможности как параметр запроса для оптимизации/ускорения работы.

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

Как пример получили скажем реализацию по всем контрагентам + отдельно необходимо вывести реализацию по избранным контрагентам
---
Akuji, Как пример получили скажем реализацию по всем контрагентам + отдельно необходимо вывести реализацию по избранным контрагентам
Можно поподробнее, почему это легче/лучше/правильнее через отбор, а не через параметр?
---
Как параметр:
потому что тебе нужен ВЕСЬ список контрагентов и часть его.
Если ты задаш отбор в парметре то ты получешь толька часть списка.
И для получения всего списка тебе придется ПОВТОРНО выполнять запрос уже без параметра.
Запрос к базе юудет выполнятся 2 раза.

Как отбор:
А так ты получаешь один раз ВЕСЬ список контрагентов и выводишь его, потом уже из этой же выборки делаешь отбор по нужным и выводишь отдельно их... Запрос к базе будет выполнятся 1 раз.
---
Не хватает понимания чем принципиально отличается "отбор" от "параметров", киньте ссылкой или объясните на пальцах, плиз.
про скд ни слова), хоть и вытекает от туда.
ищем отличия.
правд уже поднадоело.
---
Тема СКД. Параметры vs Отбор. Но эт понятно, иногда в пылу обсуждения теряется сам вопрос обсуждения )
---
тем более в пятницу после обеда
---
Akuji, существенно.
погодка шепчет. летом так хорошо не было
---
ну так то ничего и не меняется...
параметры полюбому попадают в запрос как пармаметры запроса... (ну если они не обязательные не считаем - тут если его не задают то его нет просто)
а отбор СКД бытается запихнуть в параметр если не получается то просто накладывает фильтр на итоговую выборку.

склоняюсь ко второму чаще в практике, отбор отключить легче, чем сделать не обязательный параметр. ИМХО.
---
Akuji, отбор СКД бытается запихнуть в параметр
обоснуй. типа как бы не недоверие, но хотелось бы доку или разум
---
(37)

была, была такая тема...
http://infostart.ru/public/124312/ пункт 8

косвенно об этом можно прочитать
http://www.forum.mista.ru/topic.php?id=613054&page=1
http://www.miko.ru/blogs/metalblog/99/

ну или посмотреть Гилёва
http://www.dealt.ru/post1

(46)

таки нет... рекомендации УЦ 1С (Гончаров, Габец) и Гилева (видео выше) прямо говорят нам, что СКД - это очень очень хитрая весчь и запрос в СКД - это сырец, который лучше особенно-то не ограничивать без надобности, а сделать отчет максимально гибким.
---
romansun, таки нет... рекомендации УЦ 1С (Гончаров, Габец) и Гилева (видео выше) прямо говорят нам, что СКД - это очень очень хитрая весчь и запрос в СКД - это сырец, который лучше особенно-то не ограничивать без надобности, а сделать отчет максимально гибким.

Ну дык именно в том и смысл - разработчик гадит в параметрах/запросах для формирования шаблона отчета, а юзер настраивает под себя готовый набор данных в настройках/отборах/сортировках и прочем пользовательском слое. Нет никакого смысла для разработчика напрягать сервера и пользовательские компы через отборы лишних данных из БД с использованием неэффективных по своей природе отборов.
А по поводу гибкости и полноты отчета приведу пример - есть у меня база розничной сети из 300 магазинов на обслуживании - самописный аналитический ОЛАП куб размером в SQL больше 100 Гб, и есть пара забавных отчетиков по тому кубу - в стиле гибрида ABC&XYZ анализа - так вот, если запрос не покоцать на этапе выбора данных из БД (к примеру фильтром по юрлицу или кластеру товаров), то результат формирования можно неделю ждать на оочень достойном сервере, и никакие отборы тут уже не помогут, а вот при параметризации отбора данных в запросе все очень даже прилично живёть, 1-2 минуты на отчет из 20-30 показательных страниц. И не стоит допускать юзера к таким вещам, вот набор колонок/группировок/доп реквизитов - нихай колупает, а в святое лезть ему не стоит. закончится тем, что отчет не сформируется вовсе, и именно зазраба при этом назовут криворукой макакой, а не пользователя, задавшего взаимоисключающие отборы по запросу.
Гончаров и Габец, конечно очень уважаемые личности, потому, советуя сильно не ужимать отчет на уровне источников данных они всегда уточняют, что и дикой избыточности в них тоже быть не должно. К примеру, в простейшем случае, нафига юзеру отчет, в котором больше 100 страниц ??? Его изучение в лучшем случает закончится изучением итогов по группировкам, да и то не всех :). Так что ИМХО лучше ужать отчет на уровне параметризации запроса, а уж если сильно кому-то хочется 2-3 месяца не отрываясь читать какую-нить карточку 41 счета по 100 магазинам за год - можно сделать параметр "Выбрать все", и не зачем из-за одного идиота остальным пользователям часами ждать результатов отбора по дико избыточным результатам запросов.
---
А с чего вы взяли, что СКД при использовании отборов все данные читает с SQL сервера? насколько я знаю, СКД отборы добавляет в параметры виртуальных таблиц, если не получается, то в условия "ГДЕ", а если и это невозможно, только тогда выбирает из полученных данных. Третий случай аналогичен условию "ИМЕЮЩИЕ" в запросе, что почти не увеличивает нагрузку на SQL, т.к. в любом случае условия отрабатывают после получения результата запроса. Получаем только доп.расходы на трафик между SQL и 1С серверами, но эти случаи довольно редки, т.к. возникают в результате применения условий к полям - результатам агрегатных функций. А итоги СКД считает сама, иногда точнее, чем запрос, так как, например, автоматически пропускает дублирующиеся записи, чего никогда не сделает запрос. Т.е. в этих случаях тоже с отбором мы получим более точные данные, нежели с параметром для условия "ИМЕЮЩИЕ" запроса.
---
в видео по скд гилева чтоль он показывал... точно не помню) но у меня сложилось такое мнение...
Вроде в итоговом запросе если посмотреть в консоли то можно увидеть...
А пока всем пока я домой)
---
Обычно в параметрах всегда указываю

```1c
    Где РТиУ.Контрагент В иерархии (&СписокКонтрагентов)
```

При этом отрабатывается и фильтр по элеиенту, и по группе, и по списку из элементов/групп.
---
alwiz3, таки mymyka прав, параметр не оставляет юзеру ни одного варианта, хотя согласен, что В ИЕРАРХИИ достаточно универсальный вид сравнения.
---
Провел несколько десятков замеров (отборы из структур в 500 000+ записей), разницы в скорости не обнаружил.
Для себя сделал вывод: пользоваться параметрами в СКД смысла не имеет.
---
Недавно с новеньким сотрудником глянул курс Гилева про СКД. Он там наглядно показывает, что отборы все равно приводятся к параметрам в итоговом запросе, так что да, параметры в СКД это пережиток запросов и использовать их смысла нет.
---
отборы все равно приводятся к параметрам в итоговом запросе как я и говорил, кто там обосновать просил
---
Как правильно указать в виртуальной таблице СКД?

РегистрНакопления.Продажи.Обороты({(&НачПериода1)}, {(&КонПериода1)}, Регистратор, {Номенклатура В ИЕРАРХИИ (&СписокГрупп)} И {Организация = (&Организация)})
Периоды и даты работают, а вот условие Номенклатуры и Организации нет.
---
Если быть точнее, как связать 2 условия в один? По отдельности они работают. Нужно чтобы они работали в связке, но не влияли друг на друга. То есть незаполненые группировки номенклатуры не вызывали ошибки при заполненности организации.
---
как-то так

```1c
    (2,2) В (
    ВЫБРАТЬ
    СУММА(ДваВОдном.ФильтрНмк),
    СУММА(ДваВОдном.ФильтрОрг),
    (Выбрать
    1 КАК ФильтрНмк,
    1 КАк ФильтрОрг
    {ГДЕ Номенклатура В ИЕРАРХИИ (&СписокГрупп)}

    ОБЪЕДИНИТЬ ВСЕ

    Выбрать
    1,
    1
    {ГДЕ Организация = (&Организация)}) КАК ДваВОдном
    СГРУППИРОВАТЬ ПО
    ФильтрНмк,
    ФильтрОрг

    )
```

пока не могу проверить будет это работать или нет, но идея думаю понятна
---
Мне нужно чтобы удовлетворялось обеим условиям когда оба есть, или одному из них если второе пустое. Или не одному, если оба пустые. С датами такое работает. А тут как то странно. Пока написал так.
{(Номенклатура В ИЕРАРХИИ (&СписокГрупп)
        И Организация = &Организация)}
В одной фигурной скобке. А на две фигурные скобки конструктор запросов ругался. Сейчас выведу отборы на форму и погоняю.
---
Разобрался. Вдруг кто, будет как я. СКД сам подставляет отбор в запрос или запрос потом обрабатывает. Все что совпадает по названию выборки запроса он сам условием отбора проверяет.
---
https://its.1c.ru/db/metod8dev/content/2696/hdoc

Главный отбор отчета

Применение отбора в запросах
Если возможно, условия из главного отбора помещается в текст запроса.
Отбор может быть помещен
в условие виртуальной таблицы,
в предложение ГДЕ,
в предложение ИМЕЮЩИЕ,
в зависимости от того, на какое поле накладывается отбор.

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

Пример явного указания необходимости помещения условия на поле Номенклатура в параметр виртуальной таблицы:

Копировать в буфер обмена

```1c
    ВЫБРАТЬ
    ПродажиОбороты.Контрагент,
    ПродажиОбороты.Номенклатура,
    ПродажиОбороты.КоличествоОборот,
    ПродажиОбороты.СуммаОборот
    ИЗ
    РегистрНакопления.Продажи.Обороты(, , , {(Номенклатура)}) КАК ПродажиОбороты
```

Сгенерированный запрос набора данных при применении отбора на поле Номенклатура может выглядеть следующим образом:

Копировать в буфер обмена

```1c
    ВЫБРАТЬ
    ПродажиОбороты.Контрагент КАК Контрагент,
    ПродажиОбороты.Номенклатура КАК Номенклатура,
    ПродажиОбороты.КоличествоОборот КАК КоличествоОборот,
    ПродажиОбороты.СуммаОборот КАК СуммаОборот,
    ПРЕДСТАВЛЕНИЕССЫЛКИ(ПродажиОбороты.Контрагент) КАК КонтрагентПредставление,
    ПРЕДСТАВЛЕНИЕССЫЛКИ(ПродажиОбороты.Номенклатура) КАК НоменклатураПредставление
    ИЗ
    РегистрНакопления.Продажи.Обороты(, , , Номенклатура = &П) КАК ПродажиОбороты
```

Как видно, отбор помещен в условие виртуальной таблицы.

В предложение ГДЕ условие помещается в случае если в исходном запросе набора данных явно сказано, что отбор на поле нужно помещать в предложение ГДЕ или при автоматическом заполнении. Если для набора данных указано автоматическое заполнение, то условие будет помещаться в предложение ГДЕ только в случае если отбор на поле не применилось в условии виртуальной таблицы, которая не находится в левой части соединения.