0. Lucifer93 69 17.06.19 23:52 Сейчас в теме

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

Правила запроса, которые описаны в книге "Настольная книга 1С:Эксперта по технологическим вопросам". Актуальность темы связана с тем, что современные программисты не очень любят читать и даже не знакомы с этими рекомендациями.

Перейти к публикации

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


2. Нельзя писать код с учетом косяка конкретной версии платформы. Так же не раскрыто правило на которое ссылается абцаз.
4. От запроса до плана запроса в SQL-базе пройдет много шагов, включая оптимизацию (упорядочивание условий по существующим индексам). Кроме того для выборки используются не только индексы, но и статистика - все это нелинейно. Совет может вселить ложную уверенность.
9. Неоднократно оптимизировал куски функцию путем убирания временных таблиц в пользу подзапроса. Получалось существенно быстрее.
10. Индексирование по полям временной таблицы - не серебряная пуля. Особенно есть ВТ используется в запросе один раз.
tormozit; Yashazz; +2 Ответить
3. Lucifer93 69 18.06.19 09:28 Сейчас в теме
(1) По поводу второго пункта сейчас поработаю подробнее.
4. С 4 не могу согласиться, так как при создании объектов конфигурации в SQL базе создаются индексы поиск по которым, независимо от статистики будет происходить быстрее, исходя из документации к SQL. Поэтому выборка по индексам изначально выполняется быстрее. Под статистикой Вы подразумеваете оптимизацию запроса средствами SQL? Если да, то независимо от набранной статистики запрос по индексам выполняется быстрее.
9. Я лишь единожды встречал, чтобы подзапрос работал быстрее временной таблицы. В данном случае я посчитал это исключением из правил и не стал делать на это акцент.
10. Тут, пожалуй, нужно сделать оговорку, что в некоторых случаях лучше индексировать. Поправлю статью, как только появится свободное время.
5. Lucifer93 69 18.06.19 09:41 Сейчас в теме
(3) Пункт 2 добавил свои пояснения по поводу получения реквизитов через точку.
7. alalsl 8 18.06.19 09:49 Сейчас в теме
(3) Не единожды видел, что подзапросы быстрее работают
Но использую временные таблицы)
На инфостарте уже писалось, что временные таблицы не панацея
8. Lucifer93 69 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 372 18.06.19 09:22 Сейчас в теме
4. Lucifer93 69 18.06.19 09:32 Сейчас в теме
(2) В данный момент его добавляю, каким-то чудом он решил не отображаться
6. Lucifer93 69 18.06.19 09:41 Сейчас в теме
(4) Пункт 3 добавлен с пояснениями автора
10. HAMMER_59 169 18.06.19 11:16 Сейчас в теме
Берем запрос с виртуальной таблицей периодического регистра сведений. Переносим условия из секции где в параметры виртуальной таблицы, убеждаемся что результат запроса теперь совсем другой. Делаем выводы.
12. Lucifer93 69 18.06.19 11:35 Сейчас в теме
(10) Не могу понять о чем Вы, хотелось бы пример увидеть. Что именно меняется в результате?
11. ogoneksergei 3 18.06.19 11:19 Сейчас в теме
5. Не относится в срезам последних/первых Регистров сведений. Так как использование параметров виртуальной таблицы могут дать не тот результат который нужен.
13. Lucifer93 69 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 69 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 169 18.06.19 12:09 Сейчас в теме
(13) Пример вам уже привели в 14 комментарии. Могу только добавить, что как только мы перенесем условие в параметры виртуальной таблицы периодического регистра сведений, у нас еще и скорость выполнения резко упадет, т.к. без указания даты мы просто получали таблицу последних значений, например, по ценам, которая относительна небольшая, а как только перенесли отбор в параметры виртуальной таблицы начинается перебор всей таблицы регистра, и таблица эта может быть очень не маленькой, например, еженедельная таблица цен поставщиков.
Lucifer93; ogoneksergei; +2 Ответить
19. Lucifer93 69 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 69 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 69 18.06.19 13:01 Сейчас в теме
(20) Планирую все дополнения, которые привнесет сообщество, отправить автору для анализа и изменения правил в новой редакции.
22. VmvLer 18.06.19 13:08 Сейчас в теме
(21) а чем сейчас занят сам автор, считает ракушки на Бали?

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

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


А еще теория далека от практики :) Взять например те же нормальные формы из теории БД.
49. Yashazz 2502 19.06.19 13:01 Сейчас в теме
(30) А ещё забывается, что запросы лишь получающая сторона, а есть ещё хранящая, т.е. архитектура. И под "универсальные правила запросов" пришлось бы сначала придумать "универсальную концепцию хранения данных". Один и тот же подход имеет разную эффективность в зависимости от структур и связей таблиц.
48. Yashazz 2502 19.06.19 12:58 Сейчас в теме
(25) Да уж, "неточности". В первой редакции 1С-Эксперта была пара таких "неточностей", особенно касательно блокировок, которые стоили мне проваленного экзамена по эксперту.
32. Bassgood 886 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 69 19.06.19 09:25 Сейчас в теме
(35) Простите, а какую личную материальную выгоду я имею? Еще одним интересным фактом является то, что никаких идей я целенаправленно не вносил, так как пытаюсь познакомить общественность с уже имеющимися идеями автора. Считаю, что в (32) автор больше фантазирует о возможном профессионализме недели говорит об этом серьезно.
Вам не стоит пытаться увидеть в людях только плохое.
37. VmvLer 19.06.19 09:32 Сейчас в теме
хорошее в людях проявиться самостоятельно, а плохое часто прячется, иногда за предрассудками как у вас, что почти никто не читает и обязательно необходимо показать всем букварь.
мне лично больно видеть в вас то, на что вы сами махнули рукой. (36)
40. Lucifer93 69 19.06.19 09:52 Сейчас в теме
(37) Эта статья является результатом спора на инфостарте, в котором разработчики доказывали, что использование ИЛИ в условиях является нормальным. Ссылаясь на автора книги я приводил аргументы, что это не так. Оказалось, что у многих не хватает времени на чтение, не доходят руки и тд. Отсюда желание выявить основные идеи автора и представить их в короткой статье.
43. VmvLer 19.06.19 10:29 Сейчас в теме
(40) Ссылаться на кого-то, отстаивая свою картину мира сомнительная стратегия.
Ведь можно оперировать элементарной логикой и практикой без звоночков из детства: "А вот Марь Ивановна сказала, что так нельзя..."

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

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

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

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

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


Я читал, что в MS SQL так и получается, то есть подзапросы обрабатываются как служебные временные таблицы, разве что индексирования там не происходит.
54. Yashazz 2502 19.06.19 13:10 Сейчас в теме
(52) А на момент выполнения "надзапроса" скуль уже знает статистику по подзапросу? Я раньше такого не замечал.
57. Rashid80 26 19.06.19 14:25 Сейчас в теме
(38)
У меня ровно те же наблюдения в части работы с MS SQL Server - чаще подзапросы работают быстрее чем ВТ. Ну и индексация ВТ в небольшом запросе чаще роняет перформанс.
Для постгрес могу сказать только одно - если можно не использовать его как сторадж для 1с, лучше не использовать.
60. ogidni 123 19.06.19 18:40 Сейчас в теме
(57)Подзапросы очень неудобно читать. К тому же можно вывести временные таблы на отдельный ссд массив и тогда разницы мало
47. Yashazz 2502 19.06.19 12:46 Сейчас в теме
Насчёт п.6 - ясное дело, речь лишь о "СУММА", т.к. никакие максимумы и средние механизм запроса по регистру для вас считать не станет, там только и именно суммирование.
59. slimper 198 19.06.19 16:24 Сейчас в теме
(0) Самоплюсование, зачем? Некрасиво.
61. s22 19 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 15 24.06.19 09:56 Сейчас в теме
Добавлю еще пункт про разыменование в запросе: при обращении через точку происходит разыменование полей, т.е. план запросов строит подзапрос. Речь идет о полях. для которых требуется разыменование, напр. Контрагент.Склад.Регион.
так же при выводе результатов запроса еще бывают моменты, когда платформа строит дополнительный запрос (например, когда требуется вывести пользователю информацию) для получения представления. Напр. при выводе сообщения типа .ссылка, платформа строит доп. запрос к субд для получения преставления ссылки. Конечно, это милисекунды в 3-4 знаке после запятой, но при больших числах и массовом работе, могут быть и задержки посерьезнее ))
Еще запросы в цикле - дебилизм, за который надо бить лопатой.

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

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

Вакансии

Бизнес-аналитик 1С
Москва
зарплата от 140 000 руб. до 200 000 руб.
Полный день

Программист 1С
Санкт-Петербург
зарплата от 120 000 руб.
Полный день

Консультант 1С (Бухгалтерия)
Санкт-Петербург
зарплата от 100 000 руб.
Полный день

Программист 1С
Санкт-Петербург
зарплата от 150 000 руб.
Полный день

Программист 1С
Тюмень
зарплата от 70 000 руб.
Полный день