1с нельзя задавать параметры для таблицы
1С 8.x : Оптимизация запросов
Почему запрос может работать неоптимально:
1. в виртуальных таблицах не используются параметры
2. соединения с подзапросами, условия с подзапросами, вложенные подзапросы
3. соединения с виртуальными таблицами
4. наложение условий на неиндексированные поля
5. получение данных из составного типа через точку
6. использование вложенных подзапросов (с большой вложенностью)
Подробнее:
1. В виртуальных таблицах не используются параметры
Рекомендация
Надо использовать по-максимуму параметры виртуальных таблиц (Остатки, Обороты, ОстаткиИОбороты)
Объяснение
Сперва выбираются данные для виртуальных таблиц, а потом уже на них накладываются условия, соединения и т.д. Т.е. если сделать запрос:
Код 1C v 8.х
То сперва выберется вся имеющаяся номенклатура со всеми остатками, а потом на неё наложится условие склада. Надо так:
Код 1C v 8.х
2. Соединения с подзапросами, условия с подзапросами, вложенные подзапросы
Рекомендация
Надо вообще стараться не использовать подзапросы, а переписать их во временные таблицы. Соединять следует только объекты метаданных или временные таблицы.
Объяснение
Оптимизатор СУБД часто не может составить оптимальный план выполнения таких запросов. Проблема в определении алгоритма соединения, который зависит от количества записей в выборке. При использовании временных таблиц размер выбираемых таблиц известен заранее, поэтому СУБД легче составить оптимальный план выполнения. Но при этом появляются накладные расходы на создание временных таблиц.
3. Соединения с виртуальными таблицами
Рекомендация
Перед соединениями с виртуальными таблицами их следует предварительно выбрать во временные и соединять уже с ними.
Объяснение
Виртуальные таблицы часто содержатся в нескольких физических таблицах СУБД, в итоге для их выборки составляется подзапрос, а проблемы с ним расшифрованы в п.2.
Обращения к виртуальным таблицам
Область применения: управляемое приложение, мобильное приложение, обычное приложение.
1. При использовании виртуальных таблиц в запросах, следует передавать в параметры таблиц все условия, относящиеся к данной виртуальной таблице. Не рекомендуется обращаться к виртуальным таблицам при помощи условий в секции ГДЕ и т.п.
Такой запрос будет возвращать правильный (с точки зрения функциональности) результат, но СУБД будет намного сложнее выбрать оптимальный план для его выполнения. В некоторых случаях это может привести к ошибкам оптимизатора СУБД и значительному замедлению работы запроса.
Например, следующий запрос использует секцию ГДЕ запроса для выборки из виртуальной таблицы:
Запрос.Текст = «ВЫБРАТЬ
| Номенклатура
|ИЗ
| РегистрНакопления.ТоварыНаСкладах.Остатки()
|ГДЕ
| Склад = &Склад»;
Возможно, что в результате выполнения этого запроса сначала будут выбраны все записи виртуальной таблицы, а затем из них будет отобрана часть, соответствующая заданному условию.
Рекомендуется ограничивать количество выбираемых записей на самом раннем этапе обработки запроса. Для этого следует передать условия в параметры виртуальной таблицы.
Запрос.Текст = «ВЫБРАТЬ
| Номенклатура
|ИЗ
| РегистрНакопления.ТоварыНаСкладах.Остатки(, Склад = &Склад)»;
2.1. При обращении к виртуальной таблице следует передавать в условия наиболее простые конструкции, например, «Измерение = Значение». Не рекомендуется использовать подзапросы и соединения(*) в параметрах виртуальной таблицы, так как это приводит к медленной работе запроса.
* Примечание: как явные соединения в подзапросах, так и неявные – при обращении к полям «через точку» от ссылки и соединения, добавляемые из ограничений доступа к данным (RLS), предусмотренных в ролях конфигурации.
2.2. При необходимости использовать подзапросы рекомендуется соблюдать следующие условия:
2.3. В случае, если нужно использовать несколько условий с подзапросами, следует выбрать одно, удовлетворяющее условиям выше и отфильтровывающее максимальное количество записей. Остальные условия следует накладывать на внешний запрос.
Кроме того, в ряде случаев можно обойтись и без перемещения условий на внешний запрос, если применять временные таблицы.
Например, вместо условия (неправильно):
Номенклатура В (. ) И Характеристика В (. ) И Серия В(. )
(Номенклатура, Характеристика, Серия) В (ВЫБРАТЬ Номенклатура, Характеристика, Серия ИЗ ВременнаяТаблицаТоваров)
Конструктор запросов 1С — обучение на примерах
Урок 6. Виртуальные таблицы и их использование в конструкторе запросов
Задача 1: Получить остатки номенклатуры на указанном складе на конец месяца.
Задача 2: Получить актуальную цену на конец месяца по указанной номенклатуре и типу цен.
Новые механизмы: заполнение параметров виртуальных таблиц.
Теоретическая часть урока №6
У некоторых объектов метаданных помимо основной таблицы в базе данных присутствуют виртуальные таблицы. Они облегчают доступ к некоторой информации содержащейся в основной таблице. Использовать данные виртуальных таблиц можно при помощи запросов, либо при помощи специальных методов встроенного языка 1с 8.
Рассмотрим основные виды виртуальных таблиц 1с для различных объектов метаданных:
Конструктор запросов позволяет работать с виртуальными таблицами регистров. Если у регистра есть виртуальные таблицы, то они будут находится в разделе База данных на вкладке Таблицы и поля после основной таблицы регистра.
Для того чтобы получить нужные данные из виртуальной таблицы регистра, необходимо заполнить ее параметры. Разберем заполнение параметров для основных виртуальных таблиц. Для того чтобы открыть окно параметров виртуальной таблицы, ее необходимо перенести из раздела База данных, в раздел Таблицы, выделить и нажать в кнопку Параметры виртуальной таблицы.
СрезПоследних и СрезПервых
Остатки в регистре накопления
Остатки в регистре бухгалтерии
При помощи данного параметра можно увеличить скорость выполнения запроса, исключив ненужную аналитику. Субконто в виртуальной таблице будут доступны в том порядке, в котором они стоят в массиве. Если в параметр передано меньше видов субконто, чем существует на счете, то не указанные в параметре субконто использовать нельзя. Данный параметр не является обязательным, если он не задан, то в виртуальной таблице используются все доступные субконто.
Обороты в регистре накопления
Обороты в регистре бухгалтерии
Остатки и обороты в регистре накопления
Остатки и обороты в регистре бухгалтерии
Все параметры используемые в данной таблице были описаны в предыдущих пунктах.
Обороты Дебет Кредит
Движения с субконто
Практическая часть урока №6
В данном разделе нам предстоит решить две задачи по пройденной теме.
Задача 1
Получить остатки номенклатуры на указанном складе на конец месяца.
Для простоты предположим, что весь учет товаров на складах идет по 41 счету бухгалтерского учета.
В итоге у нас получится запрос со следующим текстом:
Задача 2
Получить актуальную цену на конец месяца по указанной номенклатуре и типу цен.
В итоге у нас получится запрос со следующим текстом:
Передача временной таблицы в запрос через параметр, не работает
Всем здрасте! Передаю таблицу в запрос. Таблица с формы УФ.
Ну сначала манипуляции с таблицей, отбираю нужные поля и сворачиваю по полю Номенклатура.
И само условие на которое ругается при выполнении
Почему то как будто бы Запрос забывает что у Номенклатуры тип СправочникиСсылка.Номенклатура, т.е. я задаю сначала
а при повторном открытии типы уже пустые, и ошибка при исполнении, вот подскажите кто сталкивался, что за фигня такая происходит =)
Забыл написать ошибка выходить что поле не найдено «ТоварыВЗапрос.Номенклатура.ВидНоменклатуры» как то так
Помощь в написании контрольных, курсовых и дипломных работ здесь.
Передача значения Null через параметр в SQL запрос
Помогите разобраться с параметрами. Не получается передать через параметр значение null в SQL.
Запрос для получения временной таблицы
При построении запроса столкнулся с проблемой, выполняется только первый запрос из строки.
Запрос на сравнение по значению из временной таблицы
Доброго времени суток! Помогите правильно понять логику составления запроса по выборке. Суть.
Создание временной таблицы через переменную типа TABLE
Создать локальную таблицу с названием TEMP и полями типа дата/время, длинное целое с.
Помощь в написании контрольных, курсовых и дипломных работ здесь.
Передача через параметр объекта
В первом случае мы передаем в качестве параметра объект, следовательно значения изменяются. class.
Передача строки в функцию через параметр
Доброго времени суток! Я точно не знаю, в ту ли я категорию пишу, так как на C# только начал.
Передача строки в функцию через параметр
Доброго времени суток! Я точно не знаю, в ту ли я категорию пишу, так как на C# только начал.
[ Наглядно о непонятном ] – Про «догмы» в 1С
С того самого момента, как только «молодой» программист 1С выходит за рамки самостоятельного познания платформы, на него постепенно начинают сыпаться ограничения: «Это делай так, а не эдак!», «Так делать неправильно!», «Правильно делать так!» или «Так вообще делать нельзя!».
В то же время, если не придерживаться этих правил, сама платформа 1С продолжает работать и ошибок не выдаёт. Поэтому причина ограничений многим вдвойне непонятна.
По прошествии времени у каждого программиста появляются собственные взгляды на подобного рода утверждения. Причём эти взгляды могут не совпадать с исходными, но всегда подтверждены собственным опытом.
Давайте попробуем разобраться в навязываемых постулатах, чтобы понять – имеют они под собой основания или нет. Начнём, предполагаю, с самого популярного – с текстов запросов.
Перед тем как перейти к содержательной части, договоримся о некоторых ограничениях:
Постулат первый
«К реальным таблицам регистров писать запросы нельзя! Надо использовать виртуальные таблицы!»
Давайте представим, что в нашу базу данных приходит запрос – найти в таблице все необходимые символы для составления фразы «КУРСЫ-ПО-1С».
«Ха!» – подумаете вы, – «Проще простого!».
А теперь представьте себя на месте базы данных, и выполните этот запрос на нашей таблице:
Не знаю, как у вас, но у меня уже со второй строчки при последовательном чтении данных наступает примерно следующее состояние:
Оно и понятно – таблица содержит в 9 раз больше символов, чем нам необходимо. И все их приходится анализировать на соответствие запросу. Но что, если бы кто-то дал нам некий «шаблон»:
Который мы бы могли совместить с нашей таблицей и получить следующий объем данных:
Ничего лишнего – только то, что необходимо!
Примерно так же работают и виртуальные таблицы. Платформа их строит оптимальным образом с учётом заданных разработчиком параметров (в нашем случае шаблон – это аналог параметров). Именно поэтому очень важно правильно заполнять параметры виртуальных таблиц.
Так, при недостаточной параметризации, может быть построена виртуальная таблица следующего вида:
И опять придётся обрабатывать лишнюю информацию.
Обратите внимание! Если у виртуальной таблицы не указаны параметры, то запрос будет выполнен к реальной таблице базы данных.
Получается, что утверждение «К реальным таблицам регистров писать запросы нельзя! Надо использовать виртуальные таблицы!» верно в том случае, когда представляется возможным использование виртуальных таблиц, и эффективно работает, если правильно заполнены параметры виртуальной таблицы.
Постулат второй
«Используй индексирование!»
Мы уже попробовали поиск путём последовательного чтения каждого элемента нашей таблицы. А что, если произвести некоторую сегментацию нашей таблицы? Улучшит ли это поиск результата?
Давайте проверим это следующим образом: буквы русского алфавита разместим на жёлтом фоне, цифры – на зелёном, а специальные символы – на голубом. Буквы латинского алфавита при этом оставим без изменений:
Теперь при поиске нужных нам символов мы анализируем только ячейки с определённым цветом фона. Это позволяет сократить зону поиска и объём обрабатываемой информации, что положительно влияет на скорость выдачи результата.
Аналогично работают и индексы в «1С:Предприятие» – вся информация делится на сегменты по определённым признакам и эта сегментация помещается в отдельную таблицу.
При необходимости осуществления поиска по индексированному полю платформа вначале производит оптимизированную выборку по таблице индексов, а затем переходит к обработке информации из таблицы с данными тех строк, которые были найдены по индексам.
Вся эта информация помещается в отдельную самостоятельную таблицу базы данных и количество записей в ней может превышать количество записей в исходной таблице в разы.
Поэтому настройка индексов оправдана только в том случае, когда эффект от их использования выше, чем затраты на создание и обслуживание отдельной таблицы базы данных.
Получается, что утверждение «Используй индексирование!» имеет обоснование. Но также имеет много нюансов, которые необходимо учитывать. Это и объём индексируемых данных, и взаимодействие с другими таблицами, и вид используемой базы данных.
Например, если обрабатываемая таблица имеет небольшой объём данных, то индексирование в этом случае будет негативно влиять на быстродействие.
Постулат третий
«Не получай лишние поля!»
В отличие от предыдущих двух утверждений, с этим не поспоришь. Просто не бывает так, когда какое-то лишнее поле, полученное в результате запроса, положительно влияло бы на функционирование 1С.
Уверен, что сейчас многие готовы крикнуть в один голос – «Автор, ты пишешь прописную истину! Зачем?!». Но постойте! Наверняка в вашем опыте есть случаи проведения рефакторинга кода запроса? А теперь признайтесь – хоть раз вы говорили себе что-то вроде «не буду-ка я трогать это поле, вдруг оно где-то используется…»?
И тут начинается многообразие факторов, негативно влияющих на производительность. От банального увеличения объема результата запроса до вложенных запросов и лишних соединений.
Поэтому всегда анализируйте – какую информацию вам необходимо получить для решения конкретной задачи, и не рискуйте ради мысли «а вдруг пригодится».
Вместо заключения
В статье описана лишь малая толика того, с чем сталкивается каждый программист 1С по мере увеличения опыта. И каждый решает самостоятельно, как поступать с новыми утверждениями: использовать как аксиому, разобраться в вопросе и принимать взвешенное решение или продолжать делать так, будто ничего и не слышал.
Надеюсь, данный материал поможет кому-то приподняться на очередную ступень, а кому-то поменять свой взгляд на «входящие догмы».
P.S. А с какими «постулатами» сталкивались Вы? Пишите в комментариях – обсудим! 🙂
Об авторе
Автор статьи – Павел Ванин
PDF-версия статьи для участников группы ВКонтакте
Если Вы еще не вступили в нее – сделайте это сейчас, и в блоке ниже (на этой странице) появятся ссылки на скачивание материалов.
Комментарии / обсуждение (69):
Ну я не знаю.. Шо ругаются? А мне понравилось)) Я тех.литературу читать не люблю. Засыпаю на второй строчке. А вот так вот на пальцах – очень круто! Я много про виртуальные таблицы читала, и, кажется, даже понимала, но только теперь поверила)) и главное – прочно ЗАПОМНИЛА. Побольше таких статей! Спасибо от души!
“Получай данные из запроса через одну точку” 🙂
За рукописные рисунки – спасибо, это оригинально. И, местами даже легче воспринимается.
Я раньше так же думал: есть виртуальная таблица – надо обращаться к ней, но для виртуальных таблиц Оборотов регистров накопления Остатков я все же думаю никакой разницы нет.
“Обратите внимание! Если у виртуальной таблицы не указаны параметры, то запрос будет выполнен к реальной таблице базы данных. Источник: ©Курсы-по-1С.рф”
Вот это вообще непонятно. С чего вдруг? Я прям аж засомневалась, решила проверить. Создала пустую базу (клиент-серверную), два справочника Склад и Номенклатура, документ Приходная накладная, Расходная накладная и Регистр накопления (Остатки на складе).
По регистру получили две таблицы:
AccumRg18 – таблица движений
и AccumRgT22 – таблица итогов
Простенький запрос:
Зашла в SQL Profiler, сделала трассировку, посмотрела план запроса:
AccumRgT22 это таблица ИТОГОВ для регистра. Всё ок, никаких при этом параметров в запросе как вы видите нет, ни отборов по складу, ни отборов по номенклатуре.
Согласно же вашей логике, я должна переписывать запрос выбирая данные из таблицы движений и суммируя все приходы и расходы, чтобы получить остатки (т.е. по таблице AccumRg18). При этом перед тем как засуммировать, т.е. сгруппировать данные, SQL мне шуранет фактически весь объем данных по регистру в TempDB, а потом уже из нее считает их дабы выполнить заветное group by. Т.е. отожраное дисковое пространство и затраты на процесс записи данных из AccumRgT18 в TempDB и блокировки к TempDB в расчет не берем, а просто бегаем ребутим сервак каждые 2 часа?
katrin, добрый комментарий! Спасибо за повод для дискуссий 🙂 Для начала поясню «Обратите внимание! Если у виртуальной таблицы не указаны параметры, то запрос будет выполнен к реальной таблице базы данных. Источник: ©Курсы-по-1С.рф».
Ни в коем случае это не призыв писать вместо «запросов без параметров к виртуальным таблицам» «запросы к реальным таблицам». Наоборот, это призыв максимально эффективно использовать параметры виртуальных таблиц. Как уже отмечалось ниже в комментариях – «без установки параметров виртуальной таблицы не будут использованы преимущества по построению наиболее оптимального запроса к базе данных, которые предоставляет платформа». Если Ваш пример спроецировать на реальную работу реальных людей, то крайне редко в один момент нужны остатки по всем товарам в разрезе всех складов. Поэтому необходимо предусматривать возможность отборов. И тут думаю Вы согласитесь с тем, что запрос
будет работать лучше, чем
И это, если говорить только про получение остатков по регистрам накоплений или про срезы по регистрам сведений. Запросы же без параметров к остальным видам виртуальных таблиц очень редко (на мой взгляд) имеет здравый смысл.
Интересно то, что данный «кусочек статьи» уже был предметом дискуссий, но в обраном направлении. Там было выражено несогласие с тем, что что-то получается не из реальных таблиц – ведь кроме как реальных в базе данных других таблиц не существует! =)
И у меня возник вопрос – что участники сообщества 1С-ников понимают под термином «Виртуальная таблица» в запросе 1С? katrin, как на него ответили бы Вы?
Основная догма про виртуальные таблицы регистров: “Если запрос работает медленнее чем с реальными таблицами, проверь на какую дату рассчитаны итоги и рассчитаны ли вообще!”. Да проверь настройку обновления статистики (если это клиент-серверная конфа).
Просто наглядно внятно и понятно
Ждем продолжения и еще статей.
Павел, привет!
Очередной “рукописный” шедевр. 🙂
Кирилл, спасибо 🙂 Но до шедевра ещё далеко)
Ещё одна догма:
обычный интерфейс быстрее управляемого.
Да, это миф, на самом деле обычный интерфейс НАМНОГО быстрее управляемого..
познавательная статья, спасибо!
А рисунки базы сделали мой день сегодня! За них отдельная благодарность! 🙂
Картинки огонь. Особенно база после последовательного чтения 🙂
Автор красавчек! Молодец, всё очень доходчиво и понятно!
Цитата “Получается, что утверждение «К реальным таблицам регистров писать запросы нельзя! Надо использовать виртуальные таблицы!» верно в том случае, когда представляется возможным использование виртуальных таблиц, и эффективно работает, если правильно заполнены параметры виртуальной таблицы.” Как заполнять параметры правильно вообще ничего не сказано, можно свести к мысли если делать правильно то будет хорошо, а вот если не правильно то плохо. Для меня эта статья зря потраченное время.
Дмитрий, спасибо за уделённое статье время! Спасибо за комментарий! 🙂
Я бы добавил еще постулат:
Если поле регистра имеет составной тип и в запросе используется конкретный один тип для этого поля – используй функцию ВЫРАЗИТЬ().
Александр, отлично! Есть такое! 🙂
еще не лишним будет для полей с неограниченной длиной тоже делать выразить( как строка(50)) хотя бы. А для перечислений использовать Представление()
DoCaru, всё верно! Только Представление() лучше использовать не только для перечислений, а для всех ссылочных полей, которые планируется выводить в виде текста, например в табличный или текстовый документ.
Не точный постулат. Выразить() нужно использовать если ты получаешь данные через точку от составного поля, например, дата документа прих.накл. Иначе, если поле состоит из 120 типов, ты будешь делать 120 левых соединений со всеми вытекающими тормозами.
в каждой компании есть свои правила (традиции):
– наименование переменных/процедур/функций (например, СотрудникСтрока или СотрудникСсылка);
– наименование метаданных (например, Рарус добавляет префикс «РАР_» к создаваемым метаданным (реквизиты, документы, регистры и прочее);
– определЁнные требования к стилю написания кода (например, немало программеров пишут код как попало – то есть в каждой строчке, без пробелов перед скобками и без пробелов после запятых, табуляцию не приемлют. если бы не автоотступы для циклов, условий и прочего, то они бы писали вообще всЁ в один столбик. такой код очень сложно читать).
лично я в мир 1С пришЁл из мира С++, в который в свою очередь пришЁл из мира Асма. я активно применяю в написании кода 1С так называемую «Венгерскую нотацию», отделяю блоки кода пустыми строками, использую области (#Область … #КонецОбласти) для группировки нескольких блоков кода.
хотелось бы, чтобы у объекта метаданных было несколько модулей форм, а то бывают такие документы с 100500 обработчиками событий, что коду края и конца не видно. а так добавил бы несколько модулей форм: в одном модуле обработчики самой формы, в другой модуле – обработчики реквизитов шапки, в третьей – обработчики одной табличной части (далее ТЧ), в четвЁртой – обработчики другой ТЧ и т. д. если количество обработчиков всех ТЧ невелико, что их можно разместить и в одном модуле формы.
считаю, что это бы упростило разбор больших документов.
Обратите внимание – 1С в последних релизах выносит все в общие модули из форм документов. В самих формах только вызовы и обработчики команд.