По теме из базы знаний
Найденные решения
Основная идея отличия параметров, участвующих в условиях в запросе СКД и отборов в месте их исполнения. Запрос, выполняется на SQL сервере, соответственно и параметры влияют через условия запроса на его выполнение, а вот отбор уже фильтрует готовый результат выполнения запроса на уровне сервера предприятия. Соответственно вывода два: задание условий отбора на уровне запроса минимизирует трафик между SQL и сервером предприятия, ну и, ИМХО, думаю алгоритмы фильтрации результатов на уровне SQL серверов (даже если оно постргес или IBM) сильно эффективнее фильтрации на уровне сервера предприятия.
В случае файловой базы различия конечно поменьше и менее понятны: во первых, в теории, отбор по условиям в запросе должен приводить к частичному, а не полному считыванию набора данных из БД, а вот отбор по результатам запроса сначала отбирает все подряд, а уже поверх полного результат натягивает фильтр.
В случае файловой базы различия конечно поменьше и менее понятны: во первых, в теории, отбор по условиям в запросе должен приводить к частичному, а не полному считыванию набора данных из БД, а вот отбор по результатам запроса сначала отбирает все подряд, а уже поверх полного результат натягивает фильтр.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Параметры ты должен указывать всегда, а отбор СКД подставляет в запрос, только если он включен в настройках. Причем, СКД сама "понимает" куда лучше поставить отбор: в конструкцию "ГДЕ" или в виртуальные параметры таблицы.
Когда ты указываешь параметры в запросе, то можешь поставить только один вид сравнения "=" или "<>" или "В" итд., а в отборе пользователь может устанавливать любые виды отбора.
На есть бесплатные видеоуроки по СКД. Очень познавательно, должен сказать. Так кстати этот вопрос в одном из уроков разбирается.
Когда ты указываешь параметры в запросе, то можешь поставить только один вид сравнения "=" или "<>" или "В" итд., а в отборе пользователь может устанавливать любые виды отбора.
На есть бесплатные видеоуроки по СКД. Очень познавательно, должен сказать. Так кстати этот вопрос в одном из уроков разбирается.
(7) Поручик,
Если необходимо жестко задать значение (получить остатки по контрагенту какуму нить...) и поместить там в вт скажем,
а потом весь дальнейший запрос строится на основании этой вт уже.
Тогда контрагент параметр.
Параметр если задаешь в запросе
Параметры в СКД тоже могут быть необязательными
Если необходимо жестко задать значение (получить остатки по контрагенту какуму нить...) и поместить там в вт скажем,
а потом весь дальнейший запрос строится на основании этой вт уже.
Тогда контрагент параметр.
(13) При параметре у тебя будет выборка, например, в 1000 записей, а при отборе все существующие записи таблицы, из которых в свою очередь выведутся в табличное поле нужные 1000, согласно отбору. Разница во времени формирования выборки может отличаться в разы, а то и на порядок.
(22) tango,
и
Не уверен что вторая фраза тождественна первой...
Отбор используется для установки условий фильтрации элементов в наборах записей.
Значения параметров могут использоваться в выражениях языка запросов
Значения параметров могут использоваться в выражениях языка запросов
и
параметр "работает" в формировании таблицы, а отбор в ее отображении?
Не уверен что вторая фраза тождественна первой...
(16) mymyka,
это в случае если отбор будет через "ГДЕ",
а если задан в параметрах таблицы регистра скажем то результат уже будет содержать только таблицу после отбора.
"Жестко" значит что условие должно обязательно быть, пусть оно и задается в пользовательском режиме... но быть.
Либо один контрагент в моем примере, либо их список.
а при отборе все существующие записи таблицы, из которых в свою очередь выведутся в табличное поле нужные 1000, согласно отбору
это в случае если отбор будет через "ГДЕ",
а если задан в параметрах таблицы регистра скажем то результат уже будет содержать только таблицу после отбора.
"Жестко" значит что условие должно обязательно быть, пусть оно и задается в пользовательском режиме... но быть.
Либо один контрагент в моем примере, либо их список.
(18) Это называется не отбор, а параметры виртуальной таблицы
(28) Например потому, что условия такого отбора можно и придется менять динамически. Рано или поздно пользователь попросит вывести НЕ в списке, или В ГРУППЕ(В ИЕРАРХИИ) и т.д. В случае параметра придется переписывать запрос, в случае отбора лишь изменить поле в настройках. Другое дело, что разница во времени формирования отчета по ВСЕМ реализациям по ВСЕМ контрагентам будет существенна.
(29) Это скд, в скд запрос всегда формируется заново )
(28) Например потому, что условия такого отбора можно и придется менять динамически. Рано или поздно пользователь попросит вывести НЕ в списке, или В ГРУППЕ(В ИЕРАРХИИ) и т.д. В случае параметра придется переписывать запрос, в случае отбора лишь изменить поле в настройках. Другое дело, что разница во времени формирования отчета по ВСЕМ реализациям по ВСЕМ контрагентам будет существенна.
(29) Это скд, в скд запрос всегда формируется заново )
(38) Я немножко не про это. В параметрах мы явно указываем тип сравнения, равно/не равно/В(списке)/В ИЕРАРХИИ/ССЫЛКА/МЕЖДУ/ПОДОБНО...вроде все. Предположим по умолчанию параметр стоит с условием
Где РТиУ.Контрагент В(&СписокКонтрагентов).
Если пользователь попросит вывести реализации по любому другому условию, например НЕ в списке, что ты будешь делать?менять запрос? А в случае отбора сам пользователь может поменять тип условия и все. В параметры нужно вносить те условия, тип которых точно не будет меняться при любых условиях запроса, например Начало и Конец периода, вид РТиУ, организация и прочее.
Где РТиУ.Контрагент В(&СписокКонтрагентов).
Если пользователь попросит вывести реализации по любому другому условию, например НЕ в списке, что ты будешь делать?менять запрос? А в случае отбора сам пользователь может поменять тип условия и все. В параметры нужно вносить те условия, тип которых точно не будет меняться при любых условиях запроса, например Начало и Конец периода, вид РТиУ, организация и прочее.
(43) m-serg74, да чего их жать? Да и списаны они уже с меня. Сейчас для меня бОльшая проблема - проблема выбрать. Изначально топик балтологический так что "награждать" тут трудно, особенно когда надо наградить одного.
Подожду до понедельника, в понедельник выдам два "вознаграждения", то что объявлено, и за второе место.
Подожду до понедельника, в понедельник выдам два "вознаграждения", то что объявлено, и за второе место.
Основная идея отличия параметров, участвующих в условиях в запросе СКД и отборов в месте их исполнения. Запрос, выполняется на SQL сервере, соответственно и параметры влияют через условия запроса на его выполнение, а вот отбор уже фильтрует готовый результат выполнения запроса на уровне сервера предприятия. Соответственно вывода два: задание условий отбора на уровне запроса минимизирует трафик между SQL и сервером предприятия, ну и, ИМХО, думаю алгоритмы фильтрации результатов на уровне SQL серверов (даже если оно постргес или IBM) сильно эффективнее фильтрации на уровне сервера предприятия.
В случае файловой базы различия конечно поменьше и менее понятны: во первых, в теории, отбор по условиям в запросе должен приводить к частичному, а не полному считыванию набора данных из БД, а вот отбор по результатам запроса сначала отбирает все подряд, а уже поверх полного результат натягивает фильтр.
В случае файловой базы различия конечно поменьше и менее понятны: во первых, в теории, отбор по условиям в запросе должен приводить к частичному, а не полному считыванию набора данных из БД, а вот отбор по результатам запроса сначала отбирает все подряд, а уже поверх полного результат натягивает фильтр.
(23) Win98, Обсуждение случаев использования отбора и параметров смысла не имеет. С точки зрения корректного использования СКД РАЗРАБОТЧИК всегда должен использовать параметры и, как следствие этого, условия отборов внутри запроса СКД, а вот если ПОЛЬЗОВАТЕЛЮ не хватает заложенных фильтров в параметрах - то он уже накладывает на готовый результат фильтр по отбору. Использование же отбора РАЗРАБОТЧИКОМ не есть гут: тут и излишняя нагрузка на сервер, и увеличение потока данных меджу звеньями архитектуры, ну и возможность нагадить пользователем в отборе (его-то в отличие от параметров от пользователя не спрятать).
и фильтр еще чем то от обора надо будет отличить)
нов итоге и получается что отбор это когда в запросе через "ГДЕ" мы отбираем данные.
Если про отбор в скд, то там скд сама вроде как определяем что можно запихноть в парамет, а что нет и наложить фильтр уже в итоговую выборку.
нов итоге и получается что отбор это когда в запросе через "ГДЕ" мы отбираем данные.
Если про отбор в скд, то там скд сама вроде как определяем что можно запихноть в парамет, а что нет и наложить фильтр уже в итоговую выборку.
В итоге есть ЗАПРОС, у него могут быть параметры (если их нет выводятся все данные)
если есть то проиходит в принципе всегда отбор либо по периоду выборки, либо по реквизиту.
Параметры: период, датаостатков, отбор по реквизиту, что там еще может быть...
Если отбор происходит в запросе он является параметром запроса.
Если отбор происходит после выборки это просто отбор/фильтр уже по выборке...
Отбор необходимо задавать по возможности как параметр запроса для оптимизации/ускорения работы.
В случае если нам необходима выборка без отбора, для каких то работ... то отбор уже придется задать как фильтр на выборку.
Как пример получили скажем реализацию по всем контрагентам + отдельно необходимо вывести реализацию по избранным контрагентам
если есть то проиходит в принципе всегда отбор либо по периоду выборки, либо по реквизиту.
Параметры: период, датаостатков, отбор по реквизиту, что там еще может быть...
Если отбор происходит в запросе он является параметром запроса.
Если отбор происходит после выборки это просто отбор/фильтр уже по выборке...
Отбор необходимо задавать по возможности как параметр запроса для оптимизации/ускорения работы.
В случае если нам необходима выборка без отбора, для каких то работ... то отбор уже придется задать как фильтр на выборку.
Как пример получили скажем реализацию по всем контрагентам + отдельно необходимо вывести реализацию по избранным контрагентам
Как параметр:
потому что тебе нужен ВЕСЬ список контрагентов и часть его.
Если ты задаш отбор в парметре то ты получешь толька часть списка.
И для получения всего списка тебе придется ПОВТОРНО выполнять запрос уже без параметра.
Запрос к базе юудет выполнятся 2 раза.
Как отбор:
А так ты получаешь один раз ВЕСЬ список контрагентов и выводишь его, потом уже из этой же выборки делаешь отбор по нужным и выводишь отдельно их... Запрос к базе будет выполнятся 1 раз.
потому что тебе нужен ВЕСЬ список контрагентов и часть его.
Если ты задаш отбор в парметре то ты получешь толька часть списка.
И для получения всего списка тебе придется ПОВТОРНО выполнять запрос уже без параметра.
Запрос к базе юудет выполнятся 2 раза.
Как отбор:
А так ты получаешь один раз ВЕСЬ список контрагентов и выводишь его, потом уже из этой же выборки делаешь отбор по нужным и выводишь отдельно их... Запрос к базе будет выполнятся 1 раз.
ну так то ничего и не меняется...
параметры полюбому попадают в запрос как пармаметры запроса... (ну если они не обязательные не считаем - тут если его не задают то его нет просто)
а отбор СКД бытается запихнуть в параметр если не получается то просто накладывает фильтр на итоговую выборку.
склоняюсь ко второму чаще в практике, отбор отключить легче, чем сделать не обязательный параметр. ИМХО.
параметры полюбому попадают в запрос как пармаметры запроса... (ну если они не обязательные не считаем - тут если его не задают то его нет просто)
а отбор СКД бытается запихнуть в параметр если не получается то просто накладывает фильтр на итоговую выборку.
склоняюсь ко второму чаще в практике, отбор отключить легче, чем сделать не обязательный параметр. ИМХО.
(36)(37)
была, была такая тема...
пункт 8
косвенно об этом можно прочитать
ну или посмотреть Гилёва
(46)
таки нет... рекомендации УЦ 1С (Гончаров, Габец) и Гилева (видео выше) прямо говорят нам, что СКД - это очень очень хитрая весчь и запрос в СКД - это сырец, который лучше особенно-то не ограничивать без надобности, а сделать отчет максимально гибким.
была, была такая тема...
пункт 8
косвенно об этом можно прочитать
ну или посмотреть Гилёва
(46)
таки нет... рекомендации УЦ 1С (Гончаров, Габец) и Гилева (видео выше) прямо говорят нам, что СКД - это очень очень хитрая весчь и запрос в СКД - это сырец, который лучше особенно-то не ограничивать без надобности, а сделать отчет максимально гибким.
(47) romansun,
Ну дык именно в том и смысл - разработчик гадит в параметрах/запросах для формирования шаблона отчета, а юзер настраивает под себя готовый набор данных в настройках/отборах/сортировках и прочем пользовательском слое. Нет никакого смысла для разработчика напрягать сервера и пользовательские компы через отборы лишних данных из БД с использованием неэффективных по своей природе отборов.
А по поводу гибкости и полноты отчета приведу пример - есть у меня база розничной сети из 300 магазинов на обслуживании - самописный аналитический ОЛАП куб размером в SQL больше 100 Гб, и есть пара забавных отчетиков по тому кубу - в стиле гибрида ABC&XYZ анализа - так вот, если запрос не покоцать на этапе выбора данных из БД (к примеру фильтром по юрлицу или кластеру товаров), то результат формирования можно неделю ждать на оочень достойном сервере, и никакие отборы тут уже не помогут, а вот при параметризации отбора данных в запросе все очень даже прилично живёть, 1-2 минуты на отчет из 20-30 показательных страниц. И не стоит допускать юзера к таким вещам, вот набор колонок/группировок/доп реквизитов - нихай колупает, а в святое лезть ему не стоит. закончится тем, что отчет не сформируется вовсе, и именно зазраба при этом назовут криворукой макакой, а не пользователя, задавшего взаимоисключающие отборы по запросу.
Гончаров и Габец, конечно очень уважаемые личности, потому, советуя сильно не ужимать отчет на уровне источников данных они всегда уточняют, что и дикой избыточности в них тоже быть не должно. К примеру, в простейшем случае, нафига юзеру отчет, в котором больше 100 страниц ??? Его изучение в лучшем случает закончится изучением итогов по группировкам, да и то не всех :). Так что ИМХО лучше ужать отчет на уровне параметризации запроса, а уж если сильно кому-то хочется 2-3 месяца не отрываясь читать какую-нить карточку 41 счета по 100 магазинам за год - можно сделать параметр "Выбрать все", и не зачем из-за одного идиота остальным пользователям часами ждать результатов отбора по дико избыточным результатам запросов.
таки нет... рекомендации УЦ 1С (Гончаров, Габец) и Гилева (видео выше) прямо говорят нам, что СКД - это очень очень хитрая весчь и запрос в СКД - это сырец, который лучше особенно-то не ограничивать без надобности, а сделать отчет максимально гибким.
Ну дык именно в том и смысл - разработчик гадит в параметрах/запросах для формирования шаблона отчета, а юзер настраивает под себя готовый набор данных в настройках/отборах/сортировках и прочем пользовательском слое. Нет никакого смысла для разработчика напрягать сервера и пользовательские компы через отборы лишних данных из БД с использованием неэффективных по своей природе отборов.
А по поводу гибкости и полноты отчета приведу пример - есть у меня база розничной сети из 300 магазинов на обслуживании - самописный аналитический ОЛАП куб размером в SQL больше 100 Гб, и есть пара забавных отчетиков по тому кубу - в стиле гибрида ABC&XYZ анализа - так вот, если запрос не покоцать на этапе выбора данных из БД (к примеру фильтром по юрлицу или кластеру товаров), то результат формирования можно неделю ждать на оочень достойном сервере, и никакие отборы тут уже не помогут, а вот при параметризации отбора данных в запросе все очень даже прилично живёть, 1-2 минуты на отчет из 20-30 показательных страниц. И не стоит допускать юзера к таким вещам, вот набор колонок/группировок/доп реквизитов - нихай колупает, а в святое лезть ему не стоит. закончится тем, что отчет не сформируется вовсе, и именно зазраба при этом назовут криворукой макакой, а не пользователя, задавшего взаимоисключающие отборы по запросу.
Гончаров и Габец, конечно очень уважаемые личности, потому, советуя сильно не ужимать отчет на уровне источников данных они всегда уточняют, что и дикой избыточности в них тоже быть не должно. К примеру, в простейшем случае, нафига юзеру отчет, в котором больше 100 страниц ??? Его изучение в лучшем случает закончится изучением итогов по группировкам, да и то не всех :). Так что ИМХО лучше ужать отчет на уровне параметризации запроса, а уж если сильно кому-то хочется 2-3 месяца не отрываясь читать какую-нить карточку 41 счета по 100 магазинам за год - можно сделать параметр "Выбрать все", и не зачем из-за одного идиота остальным пользователям часами ждать результатов отбора по дико избыточным результатам запросов.
(48) А с чего вы взяли, что СКД при использовании отборов все данные читает с SQL сервера? насколько я знаю, СКД отборы добавляет в параметры виртуальных таблиц, если не получается, то в условия "ГДЕ", а если и это невозможно, только тогда выбирает из полученных данных. Третий случай аналогичен условию "ИМЕЮЩИЕ" в запросе, что почти не увеличивает нагрузку на SQL, т.к. в любом случае условия отрабатывают после получения результата запроса. Получаем только доп.расходы на трафик между SQL и 1С серверами, но эти случаи довольно редки, т.к. возникают в результате применения условий к полям - результатам агрегатных функций. А итоги СКД считает сама, иногда точнее, чем запрос, так как, например, автоматически пропускает дублирующиеся записи, чего никогда не сделает запрос. Т.е. в этих случаях тоже с отбором мы получим более точные данные, нежели с параметром для условия "ИМЕЮЩИЕ" запроса.
Как правильно указать в виртуальной таблице СКД?
РегистрНакопления.Продажи.Обороты({(&НачПериода1)}, {(&КонПериода1)}, Регистратор, {Номенклатура В ИЕРАРХИИ (&СписокГрупп)} И {Организация = (&Организация)})
Периоды и даты работают, а вот условие Номенклатуры и Организации нет.
РегистрНакопления.Продажи.Обороты({(&НачПериода1)}, {(&КонПериода1)}, Регистратор, {Номенклатура В ИЕРАРХИИ (&СписокГрупп)} И {Организация = (&Организация)})
Периоды и даты работают, а вот условие Номенклатуры и Организации нет.
(55) как-то так
пока не могу проверить будет это работать или нет, но идея думаю понятна
(2,2) В (
ВЫБРАТЬ
СУММА(ДваВОдном.ФильтрНмк),
СУММА(ДваВОдном.ФильтрОрг),
(Выбрать
1 КАК ФильтрНмк,
1 КАк ФильтрОрг
{ГДЕ Номенклатура В ИЕРАРХИИ (&СписокГрупп)}
ОБЪЕДИНИТЬ ВСЕ
Выбрать
1,
1
{ГДЕ Организация = (&Организация)}) КАК ДваВОдном
СГРУППИРОВАТЬ ПО
ФильтрНмк,
ФильтрОрг
) Показатьпока не могу проверить будет это работать или нет, но идея думаю понятна
(56) Мне нужно чтобы удовлетворялось обеим условиям когда оба есть, или одному из них если второе пустое. Или не одному, если оба пустые. С датами такое работает. А тут как то странно. Пока написал так.
{(Номенклатура В ИЕРАРХИИ (&СписокГрупп)
И Организация = &Организация)}
В одной фигурной скобке. А на две фигурные скобки конструктор запросов ругался. Сейчас выведу отборы на форму и погоняю.
{(Номенклатура В ИЕРАРХИИ (&СписокГрупп)
И Организация = &Организация)}
В одной фигурной скобке. А на две фигурные скобки конструктор запросов ругался. Сейчас выведу отборы на форму и погоняю.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот