Правила запроса, которые описаны в книге «Настольная книга 1С:Эксперта по технологическим вопросам». Актуальность темы связана с тем, что современные программисты не очень любят читать и даже не знакомы с этими рекомендациями.
При написании запросов могут быть допущены методические ошибки. Ниже перечислены правила, которых следует придерживаться. Большинство из них надо соблюдать всегда, вырабатывая правильный стиль написания кода. Однако есть правила, соблюдение которых требуется только при переписывании проблемных запросов (почему — станет ясно при ознакомлении с правилами), и для таких случаев в списке указано: «При возникновении проблем на данном участке кода».
1.Выбирать в запросе только то, что нужно.
2.Понимать, что запрос через объектную модель может не соответствовать правилу: Зафиксирован случай, когда при получении ДокументСсылка.Проведен из базы на самом деле запрашивались все реквизиты документа. Один из реквизитов имел тип ХранилищеЗначения и большой размер данных в хранилище, поэтому запрос ДокументСсылка.Проведен выполнялся очень долго. Обычно, однако, это не мешает работе, но при возникновении проблем на данном участке кода надо писать запросы на языке запросов, а не пользоваться объектной моделью.
Пояснения
3.При работе в автоматическом режиме блокировок при использовании конструкции ДЛЯ ИЗМЕНЕНИЯ надо указывать, какие таблицы блокировать, если в запросе участвует больше одной таблицы.
Пояснения
4.Условия в запросе и индексы в базе должны друг другу соответствовать (при возникновении проблем на данном участке кода).
Пояснения
5.При работе с виртуальными таблицами нужно использовать параметры виртуальных таблиц, а не выносить условия в секцию ГДЕ.
Дополнение от ogoneksergei
6.Не применять избыточное агрегирование, механизм виртуальных таблиц сам считает сумму, и так, как в примере, делать не надо:
СУММА(Остатки.СУММАВзаиморасчетовОстаток) КАК СуммаВзаиморасчетовОстаток
7.При соединении таблиц все условия и параметры, относящиеся к полям этих таблиц, ставить в условия соединения или пользоваться временными таблицами, а не оставлять их до секции ГДЕ. При этом, конечно, не должна страдать логика.
8.Не использовать подзапросы в условии соединения и в секции ГДЕ. Нужно использовать временные таблицы.
9. Вообще лучше не использовать соединения с подзапросами, а использовать временные таблицы.
Пояснения
К данному правилу имеется оговорка. Некоторые разработчики утверждают, что довольно часто встречается ситуация когда подзапрос работает быстрее. Я не призываю использовать подзапросы повсеместно, но, если скорость работы с ВТ намного ниже скорости работы с подзапросом, считаю, что данным правилом можно пренебречь
10.Не соединять виртуальные таблицы с реальными, а также виртуальные с виртуальными. Правильно сначала результат виртуальной таблицы записывать во временную таблицу, индексировать ее по полям соединения, а затем уже соединять. К данному правилу имеется оговорка. Использование индексации полей временной таблицы не всегда приводит к улучшению производительности. Будьте внимательны, применяя индексацию Вы можете увеличить время выполнения запроса
Пояснения
11.Не рекомендуется использовать логическое ИЛИ в условиях соединения, то есть в секции ПО запроса. Следует проанализировать решаемую задачу и попытаться найти другой алгоритм ее решения (при возникновении проблем на данном участке кода).
12.Аналогично с условием «Не равно», особенно если на «Не равно» сравниваются ссылки (при возникновении проблем на данном участке кода).
13.В секции ГДЕ логическое ИЛИ использовать тоже не рекомендуется. Следует разбить один запрос на несколько и объединить результаты (при возникновении проблем на данном участке кода).
14.Избегать запросов к пустым таблицам в режиме автоматического управления блокировками 1С.
15.Аккуратно пользоваться разыменованием (получением данных «через точку»):
-
Совершенно точно не пользоваться для получения данных от полей составного типа (при возникновении проблем на данном участке кода).
-
Для сравнения ссылок сравнивать только ссылки, если от этого не страдает логика (при возникновении проблем на данном участке кода менять логику).
ПО ФИО.ФизЛицо = ФизЛица.Ссылка
а не
ПО ФИО.ФизЛицо.Наименование = ФизЛица.Ссылка.Наименование
-
Не получать еще раз Ссылка
ПО ФИО.ФизЛицо = ФизЛица.Ссылка
а не
ПО ФИО.ФизЛицо.Ссылка = ФизЛица.Ссылка
-
Никогда не использовать конструкцию Ссылка.Ссылка. Это всегда ошибка
Пояснения
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Есть ряд замечаний.
2. Нельзя писать код с учетом косяка конкретной версии платформы. Так же не раскрыто правило на которое ссылается абцаз.
4. От запроса до плана запроса в SQL-базе пройдет много шагов, включая оптимизацию (упорядочивание условий по существующим индексам). Кроме того для выборки используются не только индексы, но и статистика — все это нелинейно. Совет может вселить ложную уверенность.
9. Неоднократно оптимизировал куски функцию путем убирания временных таблиц в пользу подзапроса. Получалось существенно быстрее.
10. Индексирование по полям временной таблицы — не серебряная пуля. Особенно есть ВТ используется в запросе один раз.
А где пункт №3?
(1) По поводу второго пункта сейчас поработаю подробнее.
4. С 4 не могу согласиться, так как при создании объектов конфигурации в SQL базе создаются индексы поиск по которым, независимо от статистики будет происходить быстрее, исходя из документации к SQL. Поэтому выборка по индексам изначально выполняется быстрее. Под статистикой Вы подразумеваете оптимизацию запроса средствами SQL? Если да, то независимо от набранной статистики запрос по индексам выполняется быстрее.
9. Я лишь единожды встречал, чтобы подзапрос работал быстрее временной таблицы. В данном случае я посчитал это исключением из правил и не стал делать на это акцент.
10. Тут, пожалуй, нужно сделать оговорку, что в некоторых случаях лучше индексировать. Поправлю статью, как только появится свободное время.
(2) В данный момент его добавляю, каким-то чудом он решил не отображаться
(3) Пункт 2 добавил свои пояснения по поводу получения реквизитов через точку.
(4) Пункт 3 добавлен с пояснениями автора
(3) Не единожды видел, что подзапросы быстрее работают
Но использую временные таблицы)
На инфостарте уже писалось, что временные таблицы не панацея
(7) На мой взгляд подзапросы намного сложнее поддерживать. Теряется удобночитаемость запроса. Думаю, стоит сделать оговорку в данном пункте на скорость работы подзапросов.
(8) Согласен. Для меня преимущество временных таблиц их удобочитаемость
Берем запрос с виртуальной таблицей периодического регистра сведений. Переносим условия из секции где в параметры виртуальной таблицы, убеждаемся что результат запроса теперь совсем другой. Делаем выводы.
5. Не относится в срезам последних/первых Регистров сведений. Так как использование параметров виртуальной таблицы могут дать не тот результат который нужен.
(10) Не могу понять о чем Вы, хотелось бы пример увидеть. Что именно меняется в результате?
(11) Не могу понять о чем Вы, хотелось бы пример увидеть. Что именно меняется в результате?
(13)Пример
Кадровый учет.
Регистр сведений кадровой истории.
ПЕРИОД СОТРУДНИК ВИД ДЕЙСТВИЯ
01.01.2019 Иванов Прием
01.01.2019 Петров Прием
01.05.2019 Иванов Увольнение
При выборке среза последних на 01.06.2019 если условие запроса ВидДействия = Прием установить в параметры ВТ то в результате будут две строки от 01.01.2019 так как условие будет выполняться при формировании ВТ среза последних. В результате на 01.06.2019 попадет Иванов который уволен 01.05.2019.
А если это условие вынести в ГДЕ то сначала в ВТ выберутся строки 01.01.2019 Петров и 01.05.2019 Иванов, а затем сработает отбор и в результате останется только Петров который реально принят на 01.06.2019.
(13) Пример вам уже привели в 14 комментарии. Могу только добавить, что как только мы перенесем условие в параметры виртуальной таблицы периодического регистра сведений, у нас еще и скорость выполнения резко упадет, т.к. без указания даты мы просто получали таблицу последних значений, например, по ценам, которая относительна небольшая, а как только перенесли отбор в параметры виртуальной таблицы начинается перебор всей таблицы регистра, и таблица эта может быть очень не маленькой, например, еженедельная таблица цен поставщиков.
(14) Согласен, в данном случае условие отрабатывает некорректно. Подправлю сейчас статью
6. Не очень понятен пункт, можете подробнее написать про механизм виртуальных таблиц, который сам считает сумму?
(17) Тут идет речь о том, что в регистре изначально хранится СУММАвзаиморасчетов и в запросе мы пытаемся ее просуммировать повторно.
(15) Дописал в статью пример 14! Спасибо за объяснения!
я так понимаю в этот статье готовят выпуск 2-ой части бестселлера?
или тут кружок по интересам «все лгут»?
(20) Планирую все дополнения, которые привнесет сообщество, отправить автору для анализа и изменения правил в новой редакции.
(21) а чем сейчас занят сам автор, считает ракушки на Бали?
даже если это так, то пусть считает, но зачем делать работу за кого-то,
мы, наконец, пришли к коммунизму?
(18) Эээ … допустим, а если мне нужна более крупная аналитика, что же теперь — не суммировать?
(18) Мне кажется я понял, что имел в виду автор, но лучше привести конкретный пример в статье, чтобы исключить разнотолки.
(22) Как минимум для того, чтобы программисты 1с писали качественные запросы. Например у меня в компании нет и не было человека, который мог бы мне объяснить правила запроса, стандарты разработки и прочее. Мне приходилось сидеть и читать книги, а оказалось так, что в данных книгах тоже есть неточности. Я очень рад, что сообщество столь активно проявило интерес к статье и сделать лучше одну из немногочисленных книг по 1с было бы здорово!
(25) Да и вообще было бы круто создать универсальные правила запросов, которые одобрило бы сообщество 1с.
(26) Открою вам секрет — во вселенной и нашем маленьком мирке в частности нет и не может быть ничего универсального.
Что-то может вам(нам) показаться логически верным только здесь и сейчас.
Вчера, завтра и где-то там доказанное вами утверждение вероятно будет абсурдом.
(27) Пожалуй, я с Вами не соглашусь. Не хочу спорить отдаляясь от темы.
(16) Я думаю что условие отрабатывает корректно. Просто нужно понимать правильное применение условий в виртуальных таблицах.
Если условие находится в параметрах виртуальной таблицы, как я понимаю, сначала идет выборка из реальной таблицы всех записей с учетом этих условий, а затем последние записи по периоду.
Если условия установить в ГДЕ то сначала идет выборка из реальной таблицы последних значений по периоду, а потом накладывается условие.
Применительно к моему примеру.
В первом варианте выборка делается с учетом условия в параметрах виртуальной таблицы ВидДействия — Прием. т.е. результат ВТ до выборки последних уже равен первым двум строкам.
01.01.2019 Иванов Прием
01.01.2019 Петров Прием
А во втором случае выбираются последние записи по измерениям.
01.01.2019 Иванов Прием
01.05.2019 Иванов Увольнение
Затем срабатывает условие ВидДействия — Прием и вторая строка исключается.
Как я понимаю это касаемо тех случаев когда нам нужно делать условия по ресурсам. Если в условии присутствуют только измерения, то их можно указывать только в параметрах виртуальной таблицы, так как двух строк с одинаковыми измерениями в этом случае не будет.
(27)
Вчера, завтра и где-то там доказанное вами утверждение вероятно будет абсурдом.
А еще теория далека от практики 🙂 Взять например те же нормальные формы из теории БД.
Это вчистую передрано из Филиппова, или есть что-то своё?
Потому что, например, в п.4 совершенно не освещена такая прелесть, как ВЫБОР КОГДА, а это тоже условие. И мне доводилось видеть феерическое несоответствие производительности в этой части казалось бы подходящим индексам СУБД.
(22) Не все же в этом мире делать только ради личной материальной выгоды, у человека помимо этого есть еще и такие нематериальные (по крайней мере до определенного момента времени) потребности как «стремление к развитию», «признание в проф. сообществе», «помощи другим людям» и т.д., которые в будущем собственно и приводят человека на более высокие ступени успеха, нежели многих других его коллег, которые считают подобную деятельность за «вот делать то нефига людям» и предпочитают вместо этого потратить время «на себя любимого».
p.s. Кто знает, возможно после получения автором книги этих дополнений — автора статьи пригласят из обыденной компании на интересную ему работу в фирму «1С» с кратным повышением оклада, а далее возможно поднимется и до уровня руководителя какого-нибудь отдела. Да и приятно будет видеть свои дополнения в книге, выпускаемой под редакцией фирмы «1С» — это также и очень хорошая рекомендация для потенциальных работодателей автора статьи (тем более в книге, касающейся производительности систем 1С, специалистов которых на рынке и так «раз, два и обсчитался»)
(31) Все пункты являются цитатами Филиппова. Насколько я Вас понял, Вы имеете в виду, что на ВЫБОР КОГДА не накладывается индекс? Я нигде не встречал информацию, что ВЫБОР КОГДА является причиной отбора по индексу.
(31)
(31) Проверил на практике. По полям ВЫБОР КОГДА индекс не строится. Автор в 4 пункте раскрыл все имеющиеся поля для связи по индексам. Скорее всего, ВЫБОР КОГДА начинает работать после обращения к SQL базе. То есть, мы получаем результаты запроса из SQL и потом начинается перебор значений подходящих под условия ВЫБОР КОГДА.
(32) Я думаю, что 99% копи-паста чужих мыслей и 1% своих в стартовом сообщении это именно
а крайняя категоричность
говорит о незрелости автора и прогрессирующем снобизме.
с чего он взял что не любят читать и не знакомы — сделал опрос старшеклассников в своем дворе и
сразу такой вывод?
Причем, идей от автора так и не поступило. Посему говорить о том, что из него выйдет что-то путное, в контексте профессионализма, преждевременно.
(35) Простите, а какую личную материальную выгоду я имею? Еще одним интересным фактом является то, что никаких идей я целенаправленно не вносил, так как пытаюсь познакомить общественность с уже имеющимися идеями автора. Считаю, что в (32) автор больше фантазирует о возможном профессионализме недели говорит об этом серьезно.
Вам не стоит пытаться увидеть в людях только плохое.
хорошее в людях проявиться самостоятельно, а плохое часто прячется, иногда за предрассудками как у вас, что почти никто не читает и обязательно необходимо показать всем букварь.
мне лично больно видеть в вас то, на что вы сами махнули рукой. (36)
2.
В «проф-разработке» об этом открытым текстом написано 🙂
4. Я бы сказал так — доп-индексы следует создавать только тогда, когда это действительно решает проблему производительности (зафиксирован реальный профит). Даже эффективные на первый взгляд индексы могут по факту оказываться неэффективными с точки зрения оптимизатора запросов и использоваться не будут.
9,10 — хорошо, что оговорки написали 🙂 На том же MSSQL я практически не сталкивался с ситуациями, когда вынос подзапросов (особенно тяжелых) во временные таблицы улучшал производительность. когда ухудшало — сталкивался. Хотя тут, конечно, очень многое зависит от того, как именно используется подзапрос. Возможно, это особенность моего стиля написания запросов. Индексация временных таблиц тоже никогда не приводила к заметному улучшению производительности в моей практике. Опять же, речь про MSSQL и мою личную практику. При работе с Postgresql работа оптимизатора вызывала гораздо больше wtf. Он там судя по всему гораздо более «деревянный». Поэтому там разбиение запроса на этапы может быть оправдано, чтобы не давать оптимизатору много шансов на ошибку.
(38) Я в своей практике встречал несколько раз моменты, когда индексация ВТ повышала производительность. Насколько я помню, тут вопрос в количестве строк ВТ и уникальности значений.
(37) Эта статья является результатом спора на инфостарте, в котором разработчики доказывали, что использование ИЛИ в условиях является нормальным. Ссылаясь на автора книги я приводил аргументы, что это не так. Оказалось, что у многих не хватает времени на чтение, не доходят руки и тд. Отсюда желание выявить основные идеи автора и представить их в короткой статье.
(39) В теории должно быть быстрее если соединяемые таблицы очень большие (иначе отработает не менее эффективный hash join при условиях на равенство в соединении). Но на практике так и не помогало, хотя казалось что таблицы достаточно большие 🙂
(41) Очень странно работает данный механизм. Надо будет заглянуть ему «под капот» и понять точные условия когда он эффективен. А то разговоров об этом получается много, а реальных данных нет.
(40) Ссылаться на кого-то, отстаивая свою картину мира сомнительная стратегия.
Ведь можно оперировать элементарной логикой и практикой без звоночков из детства: «А вот Марь Ивановна сказала, что так нельзя…»
ИЛИ — это ключевое слово языка запросов и его использование является нормальным без всяких доказательств.
А вот вопрос эффективности использования ИЛИ зависит от множества факторов и диспут по этому поводу мне напоминает кваканье жаб, каждая из которых хвалит свое болото.
(43)
(43)
Ссылаться на человека, который знает явно больше моего в 1с, считаю вполне нормальным. Вообще, применять рекомендации, которые написаны в рамках методической поддержки пользователю является хорошим тоном.
«ИЛИ — это ключевое слово языка запросов и его использование является нормальным без всяких доказательств.» Только вот как раз об этом и говорится, что не всегда это является нормальным. В большинстве случаев это несет потерю производительности.
То, что Вы называете «практикой без звоночков из детства» в научных кругах называется «ссылка на авторитетный источник».
(42) Думаю, что проблема как раз в том, что точные условия будет вывести проблематично. Слишком много факторов из конкретного окружения влияют на выбор оптимального плана. Поэтому справедлива общая рекомендация — писать как проще, но без явных косяков а оптимизацией заниматься когда появляются узкие места.
Создание доп-индексов — это обычно уже оптимизация и она не бесплатна. Хотя бывают конечно случаи, когда уже на этапе проектирования необходимость доп-индекса совершенно очевидна. Ну, то есть заранее известно что таблица будет очень большая, условия по этому полю будут применяться в критичных по времени выполнения запросах, а индекс по этому полю будет иметь очень высокую селективность. Другими словами, оптимизатор этим индексом точно пренебрегать не станет.
(43) В статье же написано, что заморачиваться отказом от ИЛИ стоит только при решении задач оптимизации. И это вполне разумный совет. Потому что наличие ИЛИ сразу делает невозможным применение эффективных алгоритмов с использованием хэш-таблиц. И если переписать запрос, то вполне можно получить существенную оптимизацию. Или не получить, если бутылочное горлышко было в другом месте 🙂
(1)
п. 2 Это из стандартов разработки 1С
Насчёт п.6 — ясное дело, речь лишь о «СУММА», т.к. никакие максимумы и средние механизм запроса по регистру для вас считать не станет, там только и именно суммирование.
(25) Да уж, «неточности». В первой редакции 1С-Эксперта была пара таких «неточностей», особенно касательно блокировок, которые стоили мне проваленного экзамена по эксперту.
(30) А ещё забывается, что запросы лишь получающая сторона, а есть ещё хранящая, т.е. архитектура. И под «универсальные правила запросов» пришлось бы сначала придумать «универсальную концепцию хранения данных». Один и тот же подход имеет разную эффективность в зависимости от структур и связей таблиц.
(36) Как это «какую личную выгоду»? Вы скопипастили чужую книгу и теперь на этом сшибаете стартмани на Инфостарте.
(40) Это не тянет ни на квинтэссенцию, ни даже на дайджест. Если вам приходится разъяснять, чем для среза регистра сведений отличается параметр в виртуалке от условия «где», то — ну у меня вопросов нету.
(38)
Я читал, что в MS SQL так и получается, то есть подзапросы обрабатываются как служебные временные таблицы, разве что индексирования там не происходит.
(45) Если при проектировании необходимость доп.индекса очевидна, а подозрения в «деревянности» оптимизатора есть, можно вообще выкрутиться средствами 1С, т.е. грамотно организовать нужные таблицы, добавить пару регистров сведений или ещё чего, тогда и запрос станет проще, прозрачнее и однозначнее.
(52) А на момент выполнения «надзапроса» скуль уже знает статистику по подзапросу? Я раньше такого не замечал.
(51)
(51) Не вижу ничего зазорного чего-то не знать. Это дайджест — «публикация наиболее интересных материалов из разных областей знаний, появившиеся в печати в последнее время». В данном случае я на тематическом портале делаю выдержку наиболее интересных материалов в определенной области.
По поводу «не знания» Вы так и не ответили мне на свой комментарий (31) в котором указали, что ВЫБОР КОГДА тоже условие по которому накладывается индекс, хотя практика показывает, что это не так.
(50) Пожалуй, в данном случае Вы правы. Я действительно получил стартмани за данную публикацию, но в этом и нет ничего плохого, как Вы могли заметить данная статья сумела заработать 37 добавлений в избранное, что доказывает ее полезность. Если для Вас она оказалась бесполезной Вы могли пройти дальше.
(38)
У меня ровно те же наблюдения в части работы с MS SQL Server — чаще подзапросы работают быстрее чем ВТ. Ну и индексация ВТ в небольшом запросе чаще роняет перформанс.
Для постгрес могу сказать только одно — если можно не использовать его как сторадж для 1с, лучше не использовать.
(28) напрасно)) Универсальные правила это когда не обязательно разбираться в вопросе. Они не нужны, когда есть понимает как работает СУБД, как влияете архитектура решения и сложность самого запроса, как посмотреть план выполнения, как определить самую ресурсоёмкую операцию запроса и почему именно так происходит.
(0) Самоплюсование, зачем? Некрасиво.
(57)Подзапросы очень неудобно читать. К тому же можно вывести временные таблы на отдельный ссд массив и тогда разницы мало
8. не актуально для платформы 8.3.13 и выше без режима совместимости при Postgre 11
В том случае, если в запросе используется оператор В с подзапросом, то вместо подзапроса будет использоваться соединение с таблицей, которая используется в операторе В. Данная замена применяется только в том случае, если в результате замены не изменяется результат запроса.
В режиме совместимости с версией 8.3.12 поведение не изменилось.
Источник:
Более того, изменилось дефолтное поведение. Теперь CTE-подзапрос по умолчанию будет инлайниться, если его результат используется один раз. В противном случае будет как раньше материализовываться.
Важные изменения в работе CTE в PostgreSQL 12
(15)
Недавно где-то в статье тут на инфостарте увидел, что Период в периодическом регистре сведений в платформе 8.3 стоит после измерений в индексе, так что непонятно почему должна производительность упасть.
(56) Это доказывает, что репост с нарушением авторских прав, защищаемых, между прочим, фирмой 1С, пользуется спросом. И что это в разы легче, чем сделать действительно свою самостоятельную публикацию.
Интересна позиция администрации ИС, потому как, напомню, «полное или частичное копирование материалов книги без письменного разрешения фирмы «1С-Паблишинг» запрещается». У вас есть такое разрешение?)
А так да, следуя вашей логике, и в воровстве ничего плохого нет — ворованное многие охотно скупают и пользуются)
Добавлю еще пункт про разыменование в запросе: при обращении через точку происходит разыменование полей, т.е. план запросов строит подзапрос. Речь идет о полях. для которых требуется разыменование, напр. Контрагент.Склад.Регион.
так же при выводе результатов запроса еще бывают моменты, когда платформа строит дополнительный запрос (например, когда требуется вывести пользователю информацию) для получения представления. Напр. при выводе сообщения типа .ссылка, платформа строит доп. запрос к субд для получения преставления ссылки. Конечно, это милисекунды в 3-4 знаке после запятой, но при больших числах и массовом работе, могут быть и задержки посерьезнее ))
Еще запросы в цикле — дебилизм, за который надо бить лопатой.
Еще неявные запросы в цикле, напр:
Для каждого стр из Товары цикл
стр.чтотам = стр.коечто.коегде.коекак;
КонецЦикла;
Конструкция стр.коечто.коегде.коекак в данном случае работает как дополнительный запрос с подзапросом.
Повторить перед собеседованием 🙂
Книжка у самого лежит, но мне кажется Бурмистров в своих курсов около 30 ти пунктов разбирал.
Вы просто скопипастили в сокр. виде раздел из книги Филиппова и выложили на ИС? А чего, так можно было?