Правила запроса. Выдержки из книги "Настольная книга 1С:Эксперта по технологическим вопросам"

Публикация № 1078667

Программирование - Практика программирования

Правила запросы

62
Правила запроса, которые описаны в книге "Настольная книга 1С:Эксперта по технологическим вопросам". Актуальность темы связана с тем, что современные программисты не очень любят читать и даже не знакомы с этими рекомендациями.
При написании запросов могут быть допущены методические ошибки. Ниже пере­числены правила, которых следует придерживаться. Большинство из них надо соблю­дать всегда, вырабатывая правильный стиль написания кода. Однако есть правила, соблюдение которых требуется только при переписывании проблемных запросов (почему — станет ясно при ознакомлении с правилами), и для таких случаев в списке указано: «При возникновении проблем на данном участке кода».
1.Выбирать в запросе только то, что нужно.
 
2.Понимать, что запрос через объектную модель может не соответствовать правилу:  Зафиксирован случай, когда при получении ДокументСсылка.Проведен из базы на самом деле запрашивались все реквизиты документа. Один из реквизитов имел тип ХранилищеЗначения и большой размер данных в хранилище, поэтому запрос ДокументСсылка.Проведен выполнялся очень долго. Обычно, однако, это не мешает работе, но при возникновении проблем на данном участке кода надо писать запросы на языке запросов, а не пользоваться объектной моделью.
 
 Пояснения
 
3.При работе в автоматическом режиме блокировок при использовании конструкции ДЛЯ ИЗМЕНЕНИЯ надо указывать, какие таблицы блокировать, если в запросе участвует больше одной таблицы. 
 
 Пояснения
 
4.Условия в запросе и индексы в базе должны друг другу соответствовать (при возникновении проблем на данном участке кода).  
 
 Пояснения
 
5.При работе с виртуальными таблицами нужно использовать параметры вирту­альных таблиц, а не выносить условия в секцию ГДЕ.
 
 Дополнение от ogoneksergei
 
6.Не применять избыточное агрегирование, механизм виртуальных таблиц сам считает сумму, и так, как в примере, делать не надо:
СУММА(Остатки.СУММАВзаиморасчетовОстаток) КАК СуммаВзаиморасчетовОстаток
7.При соединении таблиц все условия и параметры, относящиеся к полям этих таблиц, ставить в условия соединения или пользоваться временными таблицами, а не оставлять их до секции ГДЕ. При этом, конечно, не должна страдать логика.
 
8.Не использовать подзапросы в условии соединения и в секции ГДЕ. Нужно использовать временные таблицы. 
 
9. Вообще лучше не использовать соединения с подзапросами, а использовать временные таблицы. 
 
 Пояснения
К данному правилу имеется оговорка. Некоторые разработчики утверждают, что довольно часто встречается ситуация когда подзапрос работает быстрее. Я не призываю использовать подзапросы повсеместно, но, если скорость работы с ВТ намного ниже скорости работы с подзапросом, считаю, что данным правилом можно пренебречь
10.Не соединять виртуальные таблицы с реальными, а также виртуальные с вирту­альными. Правильно сначала результат виртуальной таблицы записывать во временную таблицу, индексировать ее по полям соединения, а затем уже соеди­нять.  К данному правилу имеется оговорка. Использование индексации полей временной таблицы не всегда приводит к улучшению производительности. Будьте внимательны, применяя индексацию Вы можете увеличить время выполнения запроса
 
 Пояснения
 
11.Не рекомендуется использовать логическое ИЛИ в условиях соединения, то есть в секции ПО запроса. Следует проанализировать решаемую задачу и попытаться найти другой алгоритм ее решения (при возникновении проблем на данном участке кода).
 
12.Аналогично с условием «Не равно», особенно если на «Не равно» сравниваются ссылки (при возникновении проблем на данном участке кода).
 
13.В секции ГДЕ логическое ИЛИ использовать тоже не рекомендуется. Следует разбить один запрос на несколько и объединить результаты (при возникновении проблем на данном участке кода). 
 
14.Избегать запросов к пустым таблицам в режиме автоматического управления блокировками 1С. 
 
15.Аккуратно пользоваться разыменованием (получением данных «через точку»):
  • Совершенно точно не пользоваться для получения данных от полей состав­ного типа (при возникновении проблем на данном участке кода). 
  • Для сравнения ссылок сравнивать только ссылки, если от этого не страдает логика (при возникновении проблем на данном участке кода менять логику).
ПО ФИО.ФизЛицо = ФизЛица.Ссылка

а не

ПО ФИО.ФизЛицо.Наименование = ФизЛица.Ссылка.Наименование
  
  • Не получать еще раз Ссылка
ПО ФИО.ФизЛицо = ФизЛица.Ссылка

а не

ПО ФИО.ФизЛицо.Ссылка = ФизЛица.Ссылка
  • Никогда не использовать конструкцию Ссылка.Ссылка. Это всегда ошибка
 
 Пояснения
 
Очень надеюсь, что данная статья будет кому-то полезна! Спасибо за внимание! 
62

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. Rashid80 26 18.06.19 09:14 Сейчас в теме
Есть ряд замечаний.


2. Нельзя писать код с учетом косяка конкретной версии платформы. Так же не раскрыто правило на которое ссылается абцаз.
4. От запроса до плана запроса в SQL-базе пройдет много шагов, включая оптимизацию (упорядочивание условий по существующим индексам). Кроме того для выборки используются не только индексы, но и статистика - все это нелинейно. Совет может вселить ложную уверенность.
9. Неоднократно оптимизировал куски функцию путем убирания временных таблиц в пользу подзапроса. Получалось существенно быстрее.
10. Индексирование по полям временной таблицы - не серебряная пуля. Особенно есть ВТ используется в запросе один раз.
tormozit; Yashazz; +2 Ответить
3. Lucifer93 66 18.06.19 09:28 Сейчас в теме
(1) По поводу второго пункта сейчас поработаю подробнее.
4. С 4 не могу согласиться, так как при создании объектов конфигурации в SQL базе создаются индексы поиск по которым, независимо от статистики будет происходить быстрее, исходя из документации к SQL. Поэтому выборка по индексам изначально выполняется быстрее. Под статистикой Вы подразумеваете оптимизацию запроса средствами SQL? Если да, то независимо от набранной статистики запрос по индексам выполняется быстрее.
9. Я лишь единожды встречал, чтобы подзапрос работал быстрее временной таблицы. В данном случае я посчитал это исключением из правил и не стал делать на это акцент.
10. Тут, пожалуй, нужно сделать оговорку, что в некоторых случаях лучше индексировать. Поправлю статью, как только появится свободное время.
5. Lucifer93 66 18.06.19 09:41 Сейчас в теме
(3) Пункт 2 добавил свои пояснения по поводу получения реквизитов через точку.
7. alalsl 8 18.06.19 09:49 Сейчас в теме
(3) Не единожды видел, что подзапросы быстрее работают
Но использую временные таблицы)
На инфостарте уже писалось, что временные таблицы не панацея
8. Lucifer93 66 18.06.19 09:51 Сейчас в теме
(7) На мой взгляд подзапросы намного сложнее поддерживать. Теряется удобночитаемость запроса. Думаю, стоит сделать оговорку в данном пункте на скорость работы подзапросов.
9. alalsl 8 18.06.19 09:54 Сейчас в теме
(8) Согласен. Для меня преимущество временных таблиц их удобочитаемость
Summer_13; GreenDragon; +2 Ответить
46. echo77 1081 19.06.19 11:29 Сейчас в теме
(1)
п. 2 Это из стандартов разработки 1С https://bit.ly/2Ro7X2a
2. the1 360 18.06.19 09:22 Сейчас в теме
4. Lucifer93 66 18.06.19 09:32 Сейчас в теме
(2) В данный момент его добавляю, каким-то чудом он решил не отображаться
6. Lucifer93 66 18.06.19 09:41 Сейчас в теме
(4) Пункт 3 добавлен с пояснениями автора
10. HAMMER_59 166 18.06.19 11:16 Сейчас в теме
Берем запрос с виртуальной таблицей периодического регистра сведений. Переносим условия из секции где в параметры виртуальной таблицы, убеждаемся что результат запроса теперь совсем другой. Делаем выводы.
12. Lucifer93 66 18.06.19 11:35 Сейчас в теме
(10) Не могу понять о чем Вы, хотелось бы пример увидеть. Что именно меняется в результате?
11. ogoneksergei 3 18.06.19 11:19 Сейчас в теме
5. Не относится в срезам последних/первых Регистров сведений. Так как использование параметров виртуальной таблицы могут дать не тот результат который нужен.
13. Lucifer93 66 18.06.19 11:35 Сейчас в теме
(11) Не могу понять о чем Вы, хотелось бы пример увидеть. Что именно меняется в результате?
14. ogoneksergei 3 18.06.19 11:55 Сейчас в теме
(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.
GreenDragon; Lucifer93; HAMMER_59; +3 Ответить
16. Lucifer93 66 18.06.19 12:43 Сейчас в теме
(14) Согласен, в данном случае условие отрабатывает некорректно. Подправлю сейчас статью
29. ogoneksergei 3 18.06.19 14:55 Сейчас в теме
(16) Я думаю что условие отрабатывает корректно. Просто нужно понимать правильное применение условий в виртуальных таблицах.

Если условие находится в параметрах виртуальной таблицы, как я понимаю, сначала идет выборка из реальной таблицы всех записей с учетом этих условий, а затем последние записи по периоду.

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

Применительно к моему примеру.

В первом варианте выборка делается с учетом условия в параметрах виртуальной таблицы ВидДействия - Прием. т.е. результат ВТ до выборки последних уже равен первым двум строкам.
01.01.2019 Иванов Прием
01.01.2019 Петров Прием

А во втором случае выбираются последние записи по измерениям.
01.01.2019 Иванов Прием
01.05.2019 Иванов Увольнение
Затем срабатывает условие ВидДействия - Прием и вторая строка исключается.

Как я понимаю это касаемо тех случаев когда нам нужно делать условия по ресурсам. Если в условии присутствуют только измерения, то их можно указывать только в параметрах виртуальной таблицы, так как двух строк с одинаковыми измерениями в этом случае не будет.
15. HAMMER_59 166 18.06.19 12:09 Сейчас в теме
(13) Пример вам уже привели в 14 комментарии. Могу только добавить, что как только мы перенесем условие в параметры виртуальной таблицы периодического регистра сведений, у нас еще и скорость выполнения резко упадет, т.к. без указания даты мы просто получали таблицу последних значений, например, по ценам, которая относительна небольшая, а как только перенесли отбор в параметры виртуальной таблицы начинается перебор всей таблицы регистра, и таблица эта может быть очень не маленькой, например, еженедельная таблица цен поставщиков.
Lucifer93; ogoneksergei; +2 Ответить
19. Lucifer93 66 18.06.19 12:49 Сейчас в теме
(15) Дописал в статью пример 14! Спасибо за объяснения!
62. Monte Carlo 21.06.19 15:58 Сейчас в теме
(15)
Пример вам уже привели в 14 комментарии. Могу только добавить, что как только мы перенесем условие в параметры виртуальной таблицы периодического регистра сведений, у нас еще и скорость выполнения резко упадет, т.к. без указания даты мы просто получали таблицу последних значений, например, по ценам, которая относительна небольшая, а как только перенесли отбор в параметры виртуальной таблицы начинается перебор всей таблицы регистра, и таблица эта может быть очень не маленькой, например, еженедельная таблица цен поставщиков.

Недавно где-то в статье тут на инфостарте увидел, что Период в периодическом регистре сведений в платформе 8.3 стоит после измерений в индексе, так что непонятно почему должна производительность упасть.
17. AlexPC 18.06.19 12:44 Сейчас в теме
6. Не очень понятен пункт, можете подробнее написать про механизм виртуальных таблиц, который сам считает сумму?
18. Lucifer93 66 18.06.19 12:47 Сейчас в теме
(17) Тут идет речь о том, что в регистре изначально хранится СУММАвзаиморасчетов и в запросе мы пытаемся ее просуммировать повторно.
23. AlexPC 18.06.19 13:10 Сейчас в теме
(18) Эээ ... допустим, а если мне нужна более крупная аналитика, что же теперь - не суммировать?
24. AlexPC 18.06.19 13:16 Сейчас в теме
(18) Мне кажется я понял, что имел в виду автор, но лучше привести конкретный пример в статье, чтобы исключить разнотолки.
20. VmvLer 18.06.19 12:53 Сейчас в теме
я так понимаю в этот статье готовят выпуск 2-ой части бестселлера?
или тут кружок по интересам "все лгут"?
21. Lucifer93 66 18.06.19 13:01 Сейчас в теме
(20) Планирую все дополнения, которые привнесет сообщество, отправить автору для анализа и изменения правил в новой редакции.
22. VmvLer 18.06.19 13:08 Сейчас в теме
(21) а чем сейчас занят сам автор, считает ракушки на Бали?

даже если это так, то пусть считает, но зачем делать работу за кого-то,
мы, наконец, пришли к коммунизму?
25. Lucifer93 66 18.06.19 13:19 Сейчас в теме
(22) Как минимум для того, чтобы программисты 1с писали качественные запросы. Например у меня в компании нет и не было человека, который мог бы мне объяснить правила запроса, стандарты разработки и прочее. Мне приходилось сидеть и читать книги, а оказалось так, что в данных книгах тоже есть неточности. Я очень рад, что сообщество столь активно проявило интерес к статье и сделать лучше одну из немногочисленных книг по 1с было бы здорово!
26. Lucifer93 66 18.06.19 13:22 Сейчас в теме
(25) Да и вообще было бы круто создать универсальные правила запросов, которые одобрило бы сообщество 1с.
27. VmvLer 18.06.19 13:30 Сейчас в теме
(26) Открою вам секрет - во вселенной и нашем маленьком мирке в частности нет и не может быть ничего универсального.

Что-то может вам(нам) показаться логически верным только здесь и сейчас.
Вчера, завтра и где-то там доказанное вами утверждение вероятно будет абсурдом.
Sergey.Noskov; AlexPC; +2 Ответить
28. Lucifer93 66 18.06.19 13:38 Сейчас в теме
(27) Пожалуй, я с Вами не соглашусь. Не хочу спорить отдаляясь от темы.
58. Sergey.Noskov 1043 19.06.19 15:30 Сейчас в теме
(28) напрасно)) Универсальные правила это когда не обязательно разбираться в вопросе. Они не нужны, когда есть понимает как работает СУБД, как влияете архитектура решения и сложность самого запроса, как посмотреть план выполнения, как определить самую ресурсоёмкую операцию запроса и почему именно так происходит.
30. AlexPC 18.06.19 15:52 Сейчас в теме
(27)
Что-то может вам(нам) показаться логически верным только здесь и сейчас.
Вчера, завтра и где-то там доказанное вами утверждение вероятно будет абсурдом.


А еще теория далека от практики :) Взять например те же нормальные формы из теории БД.
49. Yashazz 2384 19.06.19 13:01 Сейчас в теме
(30) А ещё забывается, что запросы лишь получающая сторона, а есть ещё хранящая, т.е. архитектура. И под "универсальные правила запросов" пришлось бы сначала придумать "универсальную концепцию хранения данных". Один и тот же подход имеет разную эффективность в зависимости от структур и связей таблиц.
48. Yashazz 2384 19.06.19 12:58 Сейчас в теме
(25) Да уж, "неточности". В первой редакции 1С-Эксперта была пара таких "неточностей", особенно касательно блокировок, которые стоили мне проваленного экзамена по эксперту.
32. Bassgood 877 18.06.19 22:53 Сейчас в теме
(22) Не все же в этом мире делать только ради личной материальной выгоды, у человека помимо этого есть еще и такие нематериальные (по крайней мере до определенного момента времени) потребности как "стремление к развитию", "признание в проф. сообществе", "помощи другим людям" и т.д., которые в будущем собственно и приводят человека на более высокие ступени успеха, нежели многих других его коллег, которые считают подобную деятельность за "вот делать то нефига людям" и предпочитают вместо этого потратить время "на себя любимого".
p.s. Кто знает, возможно после получения автором книги этих дополнений - автора статьи пригласят из обыденной компании на интересную ему работу в фирму "1С" с кратным повышением оклада, а далее возможно поднимется и до уровня руководителя какого-нибудь отдела. Да и приятно будет видеть свои дополнения в книге, выпускаемой под редакцией фирмы "1С" - это также и очень хорошая рекомендация для потенциальных работодателей автора статьи (тем более в книге, касающейся производительности систем 1С, специалистов которых на рынке и так "раз, два и обсчитался")
Lucifer93; +1 Ответить
35. VmvLer 19.06.19 09:18 Сейчас в теме
(32) Я думаю, что 99% копи-паста чужих мыслей и 1% своих в стартовом сообщении это именно
только ради личной материальной выгоды

а крайняя категоричность
что современные программисты не очень любят читать и даже не знакомы с этими рекомендациями.

говорит о незрелости автора и прогрессирующем снобизме.
с чего он взял что не любят читать и не знакомы - сделал опрос старшеклассников в своем дворе и
сразу такой вывод?

Причем, идей от автора так и не поступило. Посему говорить о том, что из него выйдет что-то путное, в контексте профессионализма, преждевременно.
36. Lucifer93 66 19.06.19 09:25 Сейчас в теме
(35) Простите, а какую личную материальную выгоду я имею? Еще одним интересным фактом является то, что никаких идей я целенаправленно не вносил, так как пытаюсь познакомить общественность с уже имеющимися идеями автора. Считаю, что в (32) автор больше фантазирует о возможном профессионализме недели говорит об этом серьезно.
Вам не стоит пытаться увидеть в людях только плохое.
37. VmvLer 19.06.19 09:32 Сейчас в теме
хорошее в людях проявиться самостоятельно, а плохое часто прячется, иногда за предрассудками как у вас, что почти никто не читает и обязательно необходимо показать всем букварь.
мне лично больно видеть в вас то, на что вы сами махнули рукой. (36)
40. Lucifer93 66 19.06.19 09:52 Сейчас в теме
(37) Эта статья является результатом спора на инфостарте, в котором разработчики доказывали, что использование ИЛИ в условиях является нормальным. Ссылаясь на автора книги я приводил аргументы, что это не так. Оказалось, что у многих не хватает времени на чтение, не доходят руки и тд. Отсюда желание выявить основные идеи автора и представить их в короткой статье.
43. VmvLer 19.06.19 10:29 Сейчас в теме
(40) Ссылаться на кого-то, отстаивая свою картину мира сомнительная стратегия.
Ведь можно оперировать элементарной логикой и практикой без звоночков из детства: "А вот Марь Ивановна сказала, что так нельзя..."

ИЛИ - это ключевое слово языка запросов и его использование является нормальным без всяких доказательств.

А вот вопрос эффективности использования ИЛИ зависит от множества факторов и диспут по этому поводу мне напоминает кваканье жаб, каждая из которых хвалит свое болото.
44. Lucifer93 66 19.06.19 10:48 Сейчас в теме
(43)
(43)
Ссылаться на человека, который знает явно больше моего в 1с, считаю вполне нормальным. Вообще, применять рекомендации, которые написаны в рамках методической поддержки пользователю является хорошим тоном.
"ИЛИ - это ключевое слово языка запросов и его использование является нормальным без всяких доказательств." Только вот как раз об этом и говорится, что не всегда это является нормальным. В большинстве случаев это несет потерю производительности.
То, что Вы называете "практикой без звоночков из детства" в научных кругах называется "ссылка на авторитетный источник".
51. Yashazz 2384 19.06.19 13:04 Сейчас в теме
(40) Это не тянет ни на квинтэссенцию, ни даже на дайджест. Если вам приходится разъяснять, чем для среза регистра сведений отличается параметр в виртуалке от условия "где", то - ну у меня вопросов нету.
55. Lucifer93 66 19.06.19 13:19 Сейчас в теме
(51)
(51) Не вижу ничего зазорного чего-то не знать. Это дайджест - "публикация наиболее интересных материалов из разных областей знаний, появившиеся в печати в последнее время". В данном случае я на тематическом портале делаю выдержку наиболее интересных материалов в определенной области.
По поводу "не знания" Вы так и не ответили мне на свой комментарий (31) в котором указали, что ВЫБОР КОГДА тоже условие по которому накладывается индекс, хотя практика показывает, что это не так.
50. Yashazz 2384 19.06.19 13:02 Сейчас в теме
(36) Как это "какую личную выгоду"? Вы скопипастили чужую книгу и теперь на этом сшибаете стартмани на Инфостарте.
56. Lucifer93 66 19.06.19 13:22 Сейчас в теме
(50) Пожалуй, в данном случае Вы правы. Я действительно получил стартмани за данную публикацию, но в этом и нет ничего плохого, как Вы могли заметить данная статья сумела заработать 37 добавлений в избранное, что доказывает ее полезность. Если для Вас она оказалась бесполезной Вы могли пройти дальше.
63. Yashazz 2384 21.06.19 19:55 Сейчас в теме
(56) Это доказывает, что репост с нарушением авторских прав, защищаемых, между прочим, фирмой 1С, пользуется спросом. И что это в разы легче, чем сделать действительно свою самостоятельную публикацию.

Интересна позиция администрации ИС, потому как, напомню, "полное или частичное копирование материалов книги без письменного разрешения фирмы "1С-Паблишинг" запрещается". У вас есть такое разрешение?)

А так да, следуя вашей логике, и в воровстве ничего плохого нет - ворованное многие охотно скупают и пользуются)
31. Yashazz 2384 18.06.19 21:00 Сейчас в теме
Это вчистую передрано из Филиппова, или есть что-то своё?

Потому что, например, в п.4 совершенно не освещена такая прелесть, как ВЫБОР КОГДА, а это тоже условие. И мне доводилось видеть феерическое несоответствие производительности в этой части казалось бы подходящим индексам СУБД.
Artem-B; acanta; +2 Ответить
33. Lucifer93 66 19.06.19 06:11 Сейчас в теме
(31) Все пункты являются цитатами Филиппова. Насколько я Вас понял, Вы имеете в виду, что на ВЫБОР КОГДА не накладывается индекс? Я нигде не встречал информацию, что ВЫБОР КОГДА является причиной отбора по индексу.
34. Lucifer93 66 19.06.19 08:15 Сейчас в теме
(31)
(31) Проверил на практике. По полям ВЫБОР КОГДА индекс не строится. Автор в 4 пункте раскрыл все имеющиеся поля для связи по индексам. Скорее всего, ВЫБОР КОГДА начинает работать после обращения к SQL базе. То есть, мы получаем результаты запроса из SQL и потом начинается перебор значений подходящих под условия ВЫБОР КОГДА.
38. herfis 282 19.06.19 09:40 Сейчас в теме
2.
Зафиксирован случай
В "проф-разработке" об этом открытым текстом написано :)
4. Я бы сказал так - доп-индексы следует создавать только тогда, когда это действительно решает проблему производительности (зафиксирован реальный профит). Даже эффективные на первый взгляд индексы могут по факту оказываться неэффективными с точки зрения оптимизатора запросов и использоваться не будут.
9,10 - хорошо, что оговорки написали :) На том же MSSQL я практически не сталкивался с ситуациями, когда вынос подзапросов (особенно тяжелых) во временные таблицы улучшал производительность. когда ухудшало - сталкивался. Хотя тут, конечно, очень многое зависит от того, как именно используется подзапрос. Возможно, это особенность моего стиля написания запросов. Индексация временных таблиц тоже никогда не приводила к заметному улучшению производительности в моей практике. Опять же, речь про MSSQL и мою личную практику. При работе с Postgresql работа оптимизатора вызывала гораздо больше wtf. Он там судя по всему гораздо более "деревянный". Поэтому там разбиение запроса на этапы может быть оправдано, чтобы не давать оптимизатору много шансов на ошибку.
Rashid80; Yashazz; +2 Ответить
39. Lucifer93 66 19.06.19 09:48 Сейчас в теме
(38) Я в своей практике встречал несколько раз моменты, когда индексация ВТ повышала производительность. Насколько я помню, тут вопрос в количестве строк ВТ и уникальности значений.
41. herfis 282 19.06.19 10:22 Сейчас в теме
(39) В теории должно быть быстрее если соединяемые таблицы очень большие (иначе отработает не менее эффективный hash join при условиях на равенство в соединении). Но на практике так и не помогало, хотя казалось что таблицы достаточно большие :)
42. Lucifer93 66 19.06.19 10:27 Сейчас в теме
(41) Очень странно работает данный механизм. Надо будет заглянуть ему "под капот" и понять точные условия когда он эффективен. А то разговоров об этом получается много, а реальных данных нет.
45. herfis 282 19.06.19 11:19 Сейчас в теме
(42) Думаю, что проблема как раз в том, что точные условия будет вывести проблематично. Слишком много факторов из конкретного окружения влияют на выбор оптимального плана. Поэтому справедлива общая рекомендация - писать как проще, но без явных косяков а оптимизацией заниматься когда появляются узкие места.
Создание доп-индексов - это обычно уже оптимизация и она не бесплатна. Хотя бывают конечно случаи, когда уже на этапе проектирования необходимость доп-индекса совершенно очевидна. Ну, то есть заранее известно что таблица будет очень большая, условия по этому полю будут применяться в критичных по времени выполнения запросах, а индекс по этому полю будет иметь очень высокую селективность. Другими словами, оптимизатор этим индексом точно пренебрегать не станет.
(43) В статье же написано, что заморачиваться отказом от ИЛИ стоит только при решении задач оптимизации. И это вполне разумный совет. Потому что наличие ИЛИ сразу делает невозможным применение эффективных алгоритмов с использованием хэш-таблиц. И если переписать запрос, то вполне можно получить существенную оптимизацию. Или не получить, если бутылочное горлышко было в другом месте :)
53. Yashazz 2384 19.06.19 13:09 Сейчас в теме
(45) Если при проектировании необходимость доп.индекса очевидна, а подозрения в "деревянности" оптимизатора есть, можно вообще выкрутиться средствами 1С, т.е. грамотно организовать нужные таблицы, добавить пару регистров сведений или ещё чего, тогда и запрос станет проще, прозрачнее и однозначнее.
52. AlexPC 19.06.19 13:08 Сейчас в теме
(38)
На том же MSSQL я практически не сталкивался с ситуациями, когда вынос подзапросов (особенно тяжелых) во временные таблицы улучшал производительность. когда ухудшало - сталкивался


Я читал, что в MS SQL так и получается, то есть подзапросы обрабатываются как служебные временные таблицы, разве что индексирования там не происходит.
54. Yashazz 2384 19.06.19 13:10 Сейчас в теме
(52) А на момент выполнения "надзапроса" скуль уже знает статистику по подзапросу? Я раньше такого не замечал.
57. Rashid80 26 19.06.19 14:25 Сейчас в теме
(38)
У меня ровно те же наблюдения в части работы с MS SQL Server - чаще подзапросы работают быстрее чем ВТ. Ну и индексация ВТ в небольшом запросе чаще роняет перформанс.
Для постгрес могу сказать только одно - если можно не использовать его как сторадж для 1с, лучше не использовать.
60. ogidni 116 19.06.19 18:40 Сейчас в теме
(57)Подзапросы очень неудобно читать. К тому же можно вывести временные таблы на отдельный ссд массив и тогда разницы мало
47. Yashazz 2384 19.06.19 12:46 Сейчас в теме
Насчёт п.6 - ясное дело, речь лишь о "СУММА", т.к. никакие максимумы и средние механизм запроса по регистру для вас считать не станет, там только и именно суммирование.
59. slimper 198 19.06.19 16:24 Сейчас в теме
(0) Самоплюсование, зачем? Некрасиво.
61. s22 20 20.06.19 12:06 Сейчас в теме
8. не актуально для платформы 8.3.13 и выше без режима совместимости при Postgre 11

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

В режиме совместимости с версией 8.3.12 поведение не изменилось.
Источник: https://dl04.1c.ru/content/Platform/8_3_15_1469/1cv8upd_8_3_15_1469.htm#7946ee38-1178-11e8-a3f7-0050569f678a

Более того, изменилось дефолтное поведение. Теперь CTE-подзапрос по умолчанию будет инлайниться, если его результат используется один раз. В противном случае будет как раньше материализовываться.
https://habr.com/ru/post/440576/
Важные изменения в работе CTE в PostgreSQL 12
triviumfan; +1 Ответить
64. slayer-ekb 14 24.06.19 09:56 Сейчас в теме
Добавлю еще пункт про разыменование в запросе: при обращении через точку происходит разыменование полей, т.е. план запросов строит подзапрос. Речь идет о полях. для которых требуется разыменование, напр. Контрагент.Склад.Регион.
так же при выводе результатов запроса еще бывают моменты, когда платформа строит дополнительный запрос (например, когда требуется вывести пользователю информацию) для получения представления. Напр. при выводе сообщения типа .ссылка, платформа строит доп. запрос к субд для получения преставления ссылки. Конечно, это милисекунды в 3-4 знаке после запятой, но при больших числах и массовом работе, могут быть и задержки посерьезнее ))
Еще запросы в цикле - дебилизм, за который надо бить лопатой.

Еще неявные запросы в цикле, напр:
Для каждого стр из Товары цикл
стр.чтотам = стр.коечто.коегде.коекак;
КонецЦикла;

Конструкция стр.коечто.коегде.коекак в данном случае работает как дополнительный запрос с подзапросом.
65. Quantum80 24.06.19 11:20 Сейчас в теме
Повторить перед собеседованием :)
Книжка у самого лежит, но мне кажется Бурмистров в своих курсов около 30 ти пунктов разбирал.
66. Artem-B 83 01.07.19 13:28 Сейчас в теме
Вы просто скопипастили в сокр. виде раздел из книги Филиппова и выложили на ИС? А чего, так можно было?
Оставьте свое сообщение