Шепоту посвящается.
Возможно читателю покажется интересным приложение в конце статьи :
Что такое нарастающие итоги ? И зачем они нужны ?
Три подхода или кто прав ?
1. Eugeneer предлагает следующий алгоритм решения задачи получения просроченных долгов контрагентов . Организовать цикл обхода выборки контрагентов ,в каждой итерации которого выполнять "мелкий" запрос к базе и с помощью кодинга получить необходимые данные отчета. Eugeneer имеет весомый аргумент - отчет //infostart.ru/public/60670/ ,практическое тестирование которого показало неплохие результаты при размере базы УТ - 13 Гб и количестве контрагентов - более 4 тыс.
2. Ish_2 в дискуссиях с Anig99 и Eugeneer настаивал на том , что лучший вариант с точки зрения быстродействия - это сделать один запрос к базе и за один проход выборки кодингом получить все необходимые для отчета данные . Ish_2 считает весомым аргументом собственные рассуждения и умозрительные построения.
3. Anig99 предлагает уместить алгоритм получения всех данных в один пакет запросов. Anig99 имеет весомый аргумент- отчет //infostart.ru/public/58966/ , который показал хорошее быстродействие при объеме базы 120(!) Гб
В настоящий момент , автор статьи считает , что прав в споре - Anig99. Опуская аргументацию почему Eugeneer и Ish_2 неправы (пожалуй , потянет на отдельную статью о вредности "семерочного" похода при работе с таблицами БД),скажу лишь , что выбранный Anig99 подход , не предполагающий кодинга вовсе - самый простой и технологичный , при котором мы "отвязываемся" от "слабости" клиента и передаем всю обработку данных на сервер баз данных. Итак, правильный подход к решению задачи выбран. Осталась мелочь - написать эффективный запрос , обеспечивающий наилучшее быстродействие. Мелочь эту мы и рассмотрим в статье.
Рассматриваемый ниже вариант построения текста пакета запросов для решения поставленной задачи представляется автору самым оптимальным для как небольших, так и очень больших объемов данных (свыше 120-150 ГБ). В демонстрационных целях , для объяснения сути подхода к решению задача несколько упрощена . Несколько упрощен , соответственно , и предлагаемый к рассмотрению текст пакета запросов . Теперь можно приступить к делу.
Постановка задачи.
Даны две таблицы:
Таблица «Долги»
|
Контрагент |
Долг |
ДатаОтсрочки |
|
Компания |
Вступайте в нашу телеграмм-группу Инфостарт См. такжеИнструментарий разработчика Роли и права Запросы СКД Программист Руководитель проекта 1С:Предприятие 8 Платные (руб) Инструменты для разработчиков 1С 8.3: Infostart Toolkit. Автоматизация и ускорение разработки на управляемых формах. Легкость работы с 1С. 16500 руб. 02.09.2020 273398 1519 422 WEB-интеграция Запросы Программист 1С 8.3 Абонемент ($m) Post1C - это внешняя обработка, которая превращает 1С в полноценный инструмент для тестирования REST API. Всё управление сосредоточено в одном окне: настройка запроса, выполнение, просмотр ответа и генерация кода - без переключения между формами. Аналог Postman, но работающий в привычной среде 1С. 1 стартмани 02.04.2026 3382 86 priem_nv 27 Инструментарий разработчика Запросы Программист 1С:Предприятие 8 1С:Зарплата и кадры государственного учреждения 3 1С:Зарплата и Управление Персоналом 3.x Абонемент ($m) QueryConsole1C — расширение, включающее консоль запросов с поддержкой исполняемых представлений — аналогов виртуальных таблиц, основанных на методах программного интерфейса ЗУП. Оно позволяет выполнять запросы с учётом встроенной бизнес-логики, отлаживать алгоритмы получения данных и автоматически генерировать код на встроенном языке 1С. 1 стартмани 16.05.2025 12568 158 zup_dev 32
16.05.2025
86
158
32
12568
Запросы Программист Бесплатно (free) Увидел cheatsheet по SQL и захотелось нарисовать подобное, но про запросы. 18.10.2024 26058 sergey279 18 Запросы Программист 1С:Предприятие 8 1C:Бухгалтерия Бесплатно (free) Столкнулся с интересной ситуацией, которую хотел бы разобрать, ввиду её неочевидности. Речь пойдёт про использование функции запроса АВТОНОМЕРЗАПИСИ() и проблемы, которые могут возникнуть. 11.10.2024 22568 XilDen 39 Инструментарий разработчика Запросы Программист Стажер 1С:Предприятие 8 1C:Бухгалтерия Бесплатно (free) Пишем на человеческом языке, что нам надо, и получаем текст запроса на языке 1С. Используются большие языковые модели (LLM GPT) от OpenAI или Яндекс на выбор. 15.01.2024 20011 437 mkalimulin 34 Очень немногие из тех, кто занимается поддержкой MS SQL, работают с хранилищем запросов. А ведь хранилище запросов – это очень удобный, мощный и, главное, бесплатный инструмент, позволяющий быстро найти и локализовать проблему производительности и потребления ресурсов запросами. В статье расскажем о том, как использовать хранилище запросов в MS SQL и какие плюсы и минусы у него есть. 11.10.2023 28162 skovpin_sa 15 HighLoad оптимизация Запросы Мониторинг Программист Бесплатно (free) Расскажем, как найти часто повторяющиеся запросы. 05.10.2023 12299 ivanov660 3 Комментарии
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Три "никаких" использовались автором при написании пакета запросов :
1. Никаких вложенных запросов. Представленный пакет предствляет собой совокупность последовательно получаемых простых временных таблиц. 2. Никаких выражений в условиях соединения . Применение операторов и выражеий в условиях соединения повышает время исполнения запроса. 3. Никаких сложных выражений в полях выборки . В частности, оператор ВЫБОР применен лишь для двух полей в последнем запросе пакета .
Особую благодарность хочу выразить Anig99 , стойкостью своей в теме
вынудившего автора написать эту статью. Подход Anig99 к решению этой задачи , заключающийся в том , что весь алгоритм должен умещаться в один пакет запросов и не содержать кодинга , представляется автору глубоко верным. Такое же глубокое ,но уже несогласие, автор выражает по поводу алгоритма решения и техники исполнения в вышеназванной теме Anig99 . См (1).
(3) Саша, а где зл-лоба ? Обижаешь...
Ну ничего .. Сейчас попробуем. Пост (2) во второй части означает отвержение твоего алгоритма решения - раз ! осуждение техники исполнения в твоей разработке с посылом к (1) - два ! Забирай плюс назад !
6.
Шёпот теней
1786
25.11.09 16:55
Сейчас в теме
скажите пожалуйста ?
ножом - удобно резать ... топором - удобно колоть ... молотком - удобно забивать ... ключевое слово "удобно" ... хотя конечно можно-с и молотком - резать или колоть ... ... 1С поставило во главу угла запросы ... понятно SQL он и есть SQL ... ... но лично я запросами получаю максимально приближенные таблицы - только то, что Запрос делает быстро ... а вот ТАКИЕ вещи просто делаю в "результатах" ... как и много другое ... потому, что: ... 1. я не такой спец в запросах ... ... 2. и есть вещи для которых данный язык (запросов) просто не приспособлен - елементарно "сцепить" тестовые строки ... ... вотТАКОЕестьМНЕНИЕ ...
(6) Согласен, что ножом только режут, топором колят.
Цель этой статьи как раз и показать на конкретном примере , что вырежешь ножом - не вырубишь топором. Привычные топорные "семерочные" алгоритмы в "восьмерке" будут плохо работать или не работать вовсе на базах 100 -200 Гб. И правильнее писать такие отчеты ,которые будут работать на любых базах, маленьких или больших, без приписок вроде : "Ой , не для всех баз." Конкретный пример : Anig99 занялся оптимизацией отчета и перешел к варианту "один запрос" не от хорошей жизни, а потому что вывод первоначально сделанного "обычного" отчета занимал более 30 мин.
(6) Продолжим. Ведь почему неправ Ish_2 - в своем предложении сделать один запрос и за один проход выборки получит необходимую таблицу ?
Симпатично , вроде. А выборка в базе 200Гб может быть настолько большой , что сделает невозможной дальнейшую обработку и выгрузку данных с сервера на клиента. Это раз. Для больших объемов данных такая переброска данных с сервера на клиента тоже затратна. Это два. Поэтому нужно стремиться как можно плотнее использовать запросы и всю обработку выносить на сервер Бд. Клиент же должен получать готовые выходные данные , небольшие по объему. Из этой идеологии и вытекает другое построение алгоритмов , так нелюбимое в среде 1сников.
(0) Опять не выставляешь индексы для временных таблиц для тех полей, что используются в условиях соединений.
Совсем не гуд. Скулевский оптимизатор может не все понять правильно :) Укажи ему явно индексируемые поля для исключения неоднозначности.
(8) Почему-то пропустил твой комментарий - прочитал только сейчас.
В демонстрационном варианте , думаю, возможно и опустить. Но если дашь ссылку где сказано , что всегда лучше индексировать явно таблицу перед соединением в след.статьях буду ставить.
(0) Из условия задачи нифига не понял, как из первых 2 таблиц вообще можно получить итоговую таблицу :)
Откуда взялись долги и соответственно просроченные долги для накл.2 и 3 ? Что такое дата отсрочки? и почему она = 01.11? или ты что-то в описании пропустил, или условия неточны?
(9) Нет , не согласен.
Постановка задачи приведена для конкретного элементарного примера . Таблицы заполнены значениями на вкус автора, чтобы читатель мог визуально убедиться в правильности хода вычислений. И проверить "на глаз" правильность запросов. Весь продемонстрированный ход алгоритма с показом промежуточных результатов как раз показывает как из двух первых таблиц получается выходная таблица . ДатаОтсрочки - это дата , которой все суммы документов с более ранней датой считаются просроченным долгом. Обычно в начальных условиях указывается количество дней отсрочки платежа. Я пошел на упрощение и задал в начальных условиях ДатуОтсрочки. Показывать реальный запрос в статье вряд ли нужно. Текст запроса и так для статьи слишком велик . Мне не удалось его упростить и сжать сильнее.
(0) Изучаю условия и обоснования дальше.
Вопрос - нафига нам нужны лишние выборки и ограничения по месяцам/периодам ? Ведь в условии об этом нигде не сказано, нужно получить выходную таблицу, в которой нет никаких месяцев :)
(12+) Или все-таки ограничение по периодам используются для оптимизации работы запроса?
Если так, предлагаю в описании это каким-то образом обозначить. Иначе сторонний/новый наблюдатель/тестер, не читавший всю дискуссию, в роли которого я сейчас пытаюсь выступить :) , может не понять данной схемы :)
(13) Конечно , в выходной таблице никаких меСяцев нет.
Выбор периода "месяц"- это на вкус разработчика. У меня вначале демонстрационного запроса находятся суммарные итоги по месяцам (как из один из возможных вариантов). А у Саши Anig99 вначале запроса находятся суммарные итоги - по дням, потом по месяцам, потом по годам. Я мог сделать также , но для демонстрации принципа алгоритма показалось достаточным обойтись "МЕСЯЦАМИ".
17.
Шёпот теней
1786
25.11.09 19:40
Сейчас в теме
(15) ... смЕЕЕшно-с ... как только ты ставишь период месяц (разбивка отчёта по месяцам) да ещЁ с такими-то обЪёмами данными в 200 ГБ - у тебя встанет ВСЁ ...
гарантирую, что запросы по частям + ТЗ сделает всЁ гОООраздо быстрее ... проверял ! и делаю именно тАк ... ... что-то не тАк в датскомИСХ_2королевстве ... что-то не договариваем-с... да-сссс... ... нет ужжж ... каждыму инструмент своЁ предназначение - ... ... а если говорить про модное СКД - дык это и есть Запрос+ТаблицаЗначение ... ... вот ...
(17) Не-а . Не встанет на 200Гб .
Месячные итоги хранятся отдельно в базе . И обращение будет не ко всей базе , а к месячным итогам. Наоборот - все полетит. Гарантировать не спеши . Ох , не спеши. Я ведь нигде не утверждал : запрос +ТЗ медленней . Я говорил о том , что один пакет запросов - оптимальнее для разных режимов работы , разных размеров баз, для разных по силе "клиентов" и т.д. Вот чем хорошо перекладывать всю обработку на сервер. При запросе ты ведь не знаешь за какой период по конретному клиенту нужно делать запрос (может у него есть неоплаченные накладные составляющие текущий долг аж 5 лет назад). Тебе придется или делать один сумашедший запрос по всем клиентам за весь период и твоя любая "клиентская машина" захлебнется. Или же делать несколько запросов по частям выбирая весь период. Что снижает быстродействие. Время исполнения конкретного алгоритма зависит слишком от многого. Вот мы встретились с тобой . То , да сё... Пошли , конечно, прежде всего тестировать и сравнивать быстрдействие твоего метода и моего . И допустим , запрос+ТЗ сработал быстрее. Может быть такое ? Может. И ты крикнешь : Ага !!!! С тебя бутылка ! Я вспомню о делах , приму озабоченный вид и по -еврейски (прости, Аркадий) улизну. И буду прав.Потому что запрос "всё в одном" быстрее не ВСЕГДА. , а в среднем. На некоторых данных он чуть проиграет, на некоторых данных сильно выиграет, т.е. всреднем оптимальнее. Но при 200Гб ,уверен, Запрос +Тз в данной задаче захлебнется .
20.
Шёпот теней
1786
25.11.09 20:28
Сейчас в теме
пакеты запросов ...
вложенный запрос ... запрос+ТЗ ... ... чтобы понять быстродействие - нужно понять "физику" этих процессов ... тогда и писать меньше надо будет ... ВОТ мне и хочется чтобы ТЫ прояснил данную "физику" - дЫк чем оТличается вложенный_запрос от пакетного_запроса ... ... тогда можно будет и поговорить более предметно и детально ... без МЕТАфизики ... ... вотТАКОЕпредложение ... ... вот ... а вот если тЫ этого не знаешь ... ? ... ! тогда твоя статья ЭТО профанация .. гадание на кофеёной гуще ... "залезе не залезе.... или пролезе ... неее ... нЕпролезе ..." ... вОООООттакаявОООООтпрОООООвОООООкация ... ...
(20) Радченко для тебя авторитетен?
ИТС, где читал про оптимизацию запросов, с собой нет, поэтому погуглил Вот отсюда Сообщение номер 539689 Re: Оптимизация запросов 22.12.2008 16:15
ПоказатьМаксим Радченко, 1С 539689 Сами по себе вложенные запросы не страшны. Страшны соединения с вложенными подзапросами. Их использование очень затрудняет выбор оптимального плана для СУБД. Поэтому высока вероятность ошибки оптимизатора и, соответственно, катастрофического замедления запроса. Разница в производительности может быть огромной. Например, при выборе правильного плана запрос может работать 1.5 сек, а при выборе неправильного - 18 часов (это реальный случай). Поэтому следует всегда избегать соединений с вложенными подзапросами. Вместо этого надо использовать временную таблицу. При использовании временной таблицы запрос будет всегда работать стабильно быстро. Ключевое слово тут - стабильно. Запрос, содержащий соединения с вложенными подзапросами, тоже может иногда работать быстро. Но гарантировать этого нельзя. ...... Обратите внимание, что существует экзотический случай, когда вложенный подзапрос ни с кем не соединяется. То есть написано ВЫБРАТЬ ИЗ (ВЫБРАТЬ ИЗ ( ВЫБРАТЬ ИЗ ...))) и все. В этом случае использовать временные таблицы необязательно. Но можно и использовать. Никакого замедления при этом не произойдет. Резюмируя можно сказать, что всегда нужно стремиться (с помощью временных таблиц в том числе), делать запрос как можно проще. Избегать вложенных подзапросов, а особенно соединений с ними. Ну о том, что один правильный запрос в SQL версии много быстрее цикла с множеством запросов или проход по таблице значений с условиями, спорить не будем?
30.
Шёпот теней
1786
25.11.09 23:57
Сейчас в теме
(27) ... ммм ... не хочется вступать в открытую полемику не в "своей теме" ... (20) адресован к Исх_2 и более глубок чем твой ответ ... НО ? ...
1. что значит правильный ? 2. что значит быстрее ? ... вопрос заключается : если знаешь принцип построения запросов - язык прежде всего декларативный а внутри правила выборки и соединения (оптимизация на основании внутренних алгоритмов) - то тогда можно и сделать правила и ответить на вопрос: когда и где и как и в каком запросе как соединять и как выбирать ... ... а то что вложеные запросы надо переводить во временные таблицы - и так все знают - везде об этом пишут НО на уровне общих рекомендаций ... могу порекомендовать следующую ссылку и далее ссылки по всему тексту: ... ... а то, что написано ТУТ - напоминает тексты об УправленческомУчёте - и красиво и похоже на правду и хочется верить - но начинаешь повторять и не получается ... ... вот ... вопрос заключается : если знаешь принцип построения запросов - язык прежде всего декларативный а внутри правила выборки и соединения (оптимизация на основании внутренних алгоритмов) - то тогда можно и сделать правила и ответить на вопрос: когда и где и как и в каком запросе как соединять и как выбирать ...
(30)Всё не так. Язык запросов SQL (стандарт пока только один -92г.)- описание синтаксиса, он сам по себе - и внутри у него ничего не сидит. Разные производители придумывают разные оптимизаторы , например оптимизатор SQL-сервер. Описание внутренней структуры оптимизатора никто не публикует и не документирует(документация отсутствует и у оптимизатора запросов 1с в файловом варианте). И для нас он - черный ящик. Мы , строго говоря , лишь догадываемся , что там внутри и не можем "ответить на вопрос: когда и где и как и в каком запросе как соединять и как выбирать ... " Представляешь в какое положение попадает разработчик ? Написав сложный запрос с вложенными запросами - он НЕ ЗНАЕТ как запрос будет выполняться в каждом конретном случае у каждого конкретного оптимизатора разных фирм !!! Хочется себя обезапасить. и не применять вложенные запросы , которые допускают двоякость и троякость толкования. Технология временных таблиц (разбиение на мелкие запросы и заданный порядок исполнения) дает возможность написания однозначно понимаемого любым оптимизатором алгоритма действий. Второе соображение , отлаживать запрос с временными таблицами гораздо легче (последовательное выполнение временных таблиц). А как ты будет контролировать и смотреть выполнение каждого вложенного запроса ? Третье соображение : продемонстрировать для публики (см. тему) запрос с временными таблицами и показом промежуточных результатов удобнее . Легче разбираться в нем и другому программисту. Декларативность языка запросов ИЗНАЧАЛЬНО предполагает неопределеность в вопросе КАК ? В КАКОМ ПОРЯДКЕ ? и не дает на этот вопрос никакого ответа. Т.е. я напишу сейчас запрос тебе простенький( с вложенным) и ни ты и никто не скажет определенно как он будет выполняться. УФФ !
35.
Шёпот теней
1786
26.11.09 05:30
Сейчас в теме
(33), (34) ... болтун ... не верю ...
ваши и статья и комментарии разговор о повседневном, без желания обсуждать, без утверждений, без "глубины" и без "ширины" рассматриваемого вопроса ... лужа ... ... как всегда уход от желания обсуждать в сторону использования нескольких демагогических прАвил - для бега по кругу ... нет желания Зделать проблему "прозрачной", наоборот, утопить её в не связанных цифрах, чтобы оставить лазейки для бегства - типа это упрощение - вот ваша цель ... ... у вас есть хороший оппонент - ... I_G_O_R ... - вот его публикациям и комментариям я верю ... есть чему по-учиться ... и есть желание залезть в интернет ... ... вотТАКАЯкритика ...
(30) Забыл сказать еще об одном коварстве оптимизатора.
Один и тот же запрос может выполняться по - разной схеме(последовательности действий) в зависимости от размера используемых таблиц . Ты представляешь какая это засада ? И рассказ о том , что все было хорошо и работатло , а потом вдруг БАЦ и какой то мелкий запросик вместо выполнения в доли секунды - выполняется !! сутки!!! - это не байки . Это проделки оптимизатора запроса.
(21) Никаких замеров.
Это демонстрационный вариант. Оптимального алгоритма. Для возможного изучения . И не более того. (22) В тексте темы указано на это упрощение (уникальный период). По моменту времени нельзя сортировать и соединять временные таблицы. Это недостаток 1с платформы. Момент времени может использоваться только в при выборке из регистров для соединения или сортировки . По моменту времени нельзя сортировать и соединять временные таблицы.
Это недостаток 1с платформы. откуда такие данные? вот только сделал в кострукторе:
ВЫБРАТЬ
ВзаиморасчетыСРаботникамиОрганизаций.Физлицо,
ВзаиморасчетыСРаботникамиОрганизаций.Регистратор,
ВзаиморасчетыСРаботникамиОрганизаций.СуммаВзаиморасчетов КАК Сумма,
ВзаиморасчетыСРаботникамиОрганизаций.МоментВремени
ПОМЕСТИТЬ ВТДолги
ИЗ
РегистрНакопления.ВзаиморасчетыСРаботникамиОрганизаций КАК ВзаиморасчетыСРаботникамиОрганизаций
;
//////////////////////////////////////////////////////////// ПоказатьСделано допущение, что поле "Период" в справочнике "Обороты" содержит только уникальные значения.
(24) Хм..Странно. А у меня не получилось, правда, давно.
Если это так , как ты пишешь и ты проверил исполнение ,то виноват ! И не получилось еще вот что , после выгрузки в таблицу значений - сортировать по Моменту времени нельзя (неправильно получается)- это уже совсем недавно.
(24) серьезное допущение сделано намеренно с целью упрощения понимания основного принципа алгоритма. Т.е. для демонстрации.
Для реальной конфигурации конечно запрос должен быть переделан. Справочник "Обороты" - экзотика, тоже ведь серьезное допущение ,а ты его не упомянул .
(39)
ВОТ мне и хочется чтобы ТЫ прояснил данную "физику" - дЫк чем оТличается вложенный_запрос от пакетного_запроса ...
Отвечаю прямо об отличии : Вложенный запрос - это часть другого запроса.
Пакетный запрос - это совокупность последовательно выполнямых
запросов.Если ты имеешь ввиду отличия между выполнением одной и той же задачи разными способами 1. Запросом, имеющим вложенные запросы 2. Пакетным запросом ( последовательное выполнение нескольких простых запросов). И задаешь вопрос , так сказать, какова "физика" этих отличий ? То я спрашиваю , нафига я писал (30) ? Если ты понимаешь под "физикой" отличий что-то другое - дай определение этой "физики".
(39) Что касается твоей ссылки
то несомненно нужная и полезная статья , приоткрывающая дверь к кухне интерпертации запросов 1с в SQL. Но эта информация полезна для очень ограниченного круга специалистов, разрабатывающих какие -то специализированные решения на платформе 1с . Статья эта лишь на другом уровне и подробностями раскрывает ,то что есть уже у Радченко. Поэтому следует всегда избегать соединений с вложенными подзапросами. Вместо этого надо использовать временную таблицу.
При использовании временной таблицы запрос будет всегда работать стабильно быстро. Ключевое слово тут - стабильно. Запрос, содержащий соединения с вложенными подзапросами, тоже может иногда работать быстро. Но гарантировать этого нельзя. Для огромного подавляющего большинства 1с-ников этого вполне достаточно. Мало того , почти наверняка, можно сказать : 1с-ник ! Если у тебя проблемы и ты полез смотреть как 1с запрос интерпретируется в SQL-запрос - ЗНАЙ : ты не знаешь как правильно составлять запросы.
41.
Шёпот теней
1786
26.11.09 09:07
Сейчас в теме
(39) ... хм ...
вопрос1: ... дык при каких условиях и пАчему Пакетный запрос выполняется быстрее ...? вопрос2: ... дык как же Зделать Нарастающий Итог в запросе ...? самый простой тип нарастающего итога это нумерация строк запроса ... прошу тебя не влезая в дебри конфигурации: 1. покажи нАм и 2. рАсскажи нАм и 3. укАжи нам ... способы создания нарастающих итогов в запросах ... ... лично мне интересно .... сделай это дополнением к статье ... я до сих пор не умею делать нарастающие итоги ... хотя бы нумерацию освоить ... а вот понятных изложений пока не нашЁл ... только по простому - чтобы даже мне было понятно ... думаю это будет интерсно и важно и познавательно для многих ... ... вОООт ...
(41) Пакетный запрос НЕ ВЫПОЛНЯЕТСЯ БЫСТРЕЕ ,чем аналогичный правильно понятый оптимизатором запрос с вложенным запросом.
Ключевые слова здесь "правильно понятый". Чтобы избежать вероятности "неправильной понятости" и применяют пакетный запрос. Сегодня подготовлю демо-вариант с нарастающими итогами с наглядным примером.
(41) вообще-то это есть в моей статье - в самом начале....
Пакет запросов скорее всего будет выполнятся быстрее, чем объединение вложенных запросов. Причиной тому - сложность для оптимизатора SQL работы с объединением вложенных запросов. Гораздо меньше неоптимальных инструкций SQL возникает при разборе простых запросов и дальнейшей передаче по цепочке временных таблиц. З.Ы. Честное слово... Такое ощущение, что специально упускаешь из внимания некоторые моменты, которые были уже сказаны
45.
Шёпот теней
1786
26.11.09 10:23
Сейчас в теме
(43) ... помню твою статью ...
но твоЁ изложение слишком "продвинуто" и а изложение Исх_2 - запутано ... может ВЫ и понимаете - а я нет ... самое простое = как соединить две таблицы чтобы можно посчитать нарастающий итог ... хотя бы нумерация строк запроса ... а то сразу " ... Метод последовательного приближения. ..." ... ... хочется как-то более простых и наглядных примеров: типа: как составить запрос: 1. выбрать номенклатуру из папки разрезе характеристик, + 2. найти остатки в разрезе выбранныйСклад-номенклатура-характеристика, + 3. найти зарезервировано в разрезе выбранныйСклад-номенклатура-характеристика, + 4. вывести свободный остаток в разрезе выбранныйСклад-номенклатура-характеристика и даже бог с ним с разбиением по периодам ... ... если бы меня кто этому научил - последовательно и обЪясняя по шагово - спАсибо бы сказал ... ... вот ...
47.
Шёпот теней
1786
26.11.09 11:59
Сейчас в теме
(46) ... спасибо ... сегодня обязательно посмотрю, доложусь как понял ... вот ...
51.
Gilev.Vyacheslav
1923
27.11.09 21:48
Сейчас в теме
вот вам занятся не чем,
работа по вам плачет :D
53.
Шёпот теней
1786
27.11.09 23:09
Сейчас в теме
(51) ... без теории НЕТ практики ... теория ЕСТЬ основа науки ...
... кстати вам не обидно, что из 24 часов только 8 тратите на работу ... ... вот ...
(53) Любимое занятие в субботу : придираться к Шепоту.
Так вот ... без теории НЕТ практики ... теория ЕСТЬ основа науки ...
Пальцем в небо. Тяжело дается диалектический подход . Получше будет так: Научный подход подразумевает : Без теории нет практики. Без практики нет теории.
56.
Шёпот теней
1786
28.11.09 14:51
Сейчас в теме
(55) ... вах ... Ish_2 ... ах ... Ish_2 ... ох ...
... твоЁ желание придраться больше чем "Правда" и выше чем "Истина" ... ... основой науки есть повторяемый опыт как Эксперимент и Опыт как опыт ... ... поэтому его сначало "наблюдают" потом "описывают", потом "повторяют" ... ... именно поэтому без Теории нет Науки ... нет Практики ... нет Опыта ... ... хотя некоторых Теория никогда не станет Опытом пока они не получат опыт ... ... вотТАКАЯтеория ...
57.
Gilev.Vyacheslav
1923
28.11.09 14:53
Сейчас в теме
(53) Теории меня не убеждают.
Я предпочитаю находить ответы экспериментальным путем. Но своих убеждений стараюсь не то что не навязывать, а отговаривать от них. Вообщем, главное, без фанатизма. 8-)
58.
Шёпот теней
1786
28.11.09 15:43
Сейчас в теме
(57) ... смЕЕЕшно-с ...
без ТЕОРИИ нет эксперимента ... !!! ... однозначно !!! ... ... есть холерики - им проще 40 раз сбегать и один раз подумать ... ... есть меланхолики - им проще 40 раз подумать и один раз сбегать ... НО ! но сначало ТЕОРИЯ а потом Эксперимент ... ... вот ...
(57) Если автор публикует свое мнение , он уже его в каком -то смысле "навязывает". если автор при этом отговоривает читателей или занимет позицию , дескать я тут мимо проходил, - хитрость эта никакого отклика как правило не находит, а находит недоумение.
Назвался автором - будь им : "навязывай" свой взгляд ,ты этим взглядом и отличаешься от других
60.
Шёпот теней
1786
28.11.09 15:54
Сейчас в теме
(59) ... ого ... НУ НИ ЧЕГО СЕБЕ ... заявлениЦЕ ... ухххтыыы ...
(63) Дождались Евгения.
Над чем тут мозг ломать - есть. Речь ведь идет не только о решении конкретной задачи , но и об ощем подходе к использованию нарастающих итогов в запросе. Если бы ты хоть чуть-чуть расшифровал слова здесь или в статье "запрос с коррелированными подзапросами" - появилось бы еще одно решение - возможно самое оптимальное. А 8.2 и агрегатами пугать простую публику не стоит.
(65) Ссылка твоя не открывается.
1. Рейтинг - это не аргумент. Рейтинг - это повод поинтересоваться - а что там ? 2. Запрос в цикле - это зло. Широко известное еще до изобретения "семерки". Применяется исключительно редко (например тогда , когда результат общего запроса может быть оч.оч. большим по размеру.) Серверу не все равно обрабатывать кучу мелких запросов или один большой. Разумеется , быстрее будет выполнен один общий правильно составленный запрос. Хотя бы потому что, обращение к базе данных будет всего одно (а это время !). Поэтому всегда нужно стремиться к одному запросу, а не к циклу запросов. Убедиться в этом можно практическим путем. Перепиши свой отчет - сделай один запрос к базе для всех контргаентов . Получи выходную таблицу за один проход выборки. Сравни время. Один запрос , набранный в конструкторе , технологичней в использовании. Применяя "Запрос + кодинг" для больших баз ты жестко привязан к "силе клиента" , к сети и т.д, т.к. часть кодинга выполняется на "клиенте". Передавая обработку на сервер ты отвязываешься от этих проблем. Для базы 120 Гб применение твоего запороса в цикле неприемлемо в принципе. Так вот кратенько...
(67),(68) Два примера запросов отвечают на вопрос о самых продаваемых товарах.
И в полях выборки используется номенклатура. Какое отношение они имеют к задаче получения просроченных долгов контрагентов ? Чем они нам помогут ? В таком случае , возможно , лучше опубликовать статью где раскрыть замысел полностью. А вот , неравенство в условии соединения запроса (68) имеет прямое к текущей теме . Рассмотрим чаить этого запроса ВЫБРАТЬ
Продажи.Родитель КАК Родитель,
Продажи.Номенклатура КАК Номенклатура,
Продажи.Количество КАК Количество
ИЗ
Продажи КАК Продажи
ВНУТРЕННЕЕ СОЕДИНЕНИЕ Продажи КАК ПродажиНумерация
ПО Продажи.Родитель = ПродажиНумерация.Родитель
И Продажи.Количество <= ПродажиНумерация.Количество ПоказатьПредставим , что в таблице всего одна группа содержащая 10 000 товаров. (для крупных торговых сетей ничего фантастического, кстати). Тогда в результате соединения получим таблицу с количеством записей (10 000+1)/2*10 000 = 50 005 000 (сумма членов арифметической прогрессии). Т.е. размер первоначальной таблицы увеличился более в чем 5 000 раз. Последующая группировка с условием не отменяет необходимости такого соединения , а лишь при получении выходной выборки фильтрует промежуточную таблицу. Ты не видишь здесь никакой проблемы ? Так вот текущая статья и статья Anig99 посвящены как раз тому , чтобы избежать таких больших промежуточных таблиц в процессе исполнения запроса. Приведенный пример не выдумка . С подобной ситуацией столкнулся Anig99 при работе с базой 120Гб. Поэтому приводя тексты таких запросов лучше предупреждать пользователя : "Этот запрос пригоден для небольшого количества данных (малые базы до 30Гб). Не вздумайте применять такие подходы для больших баз (более 120 Гб)."
89.
Шёпот теней
1786
01.12.09 21:59
Сейчас в теме
(86) ... ГИГАнтоМАНИЯ ...
... гипноз нулей ... ... кто больше ... 100 ГБ ... 120 ГБ ... 150 ГБ ... 200 ГБ ... 80 000 строк ... ... сумма членов арифметической прогрессии ... ... прямь как в рекламе : не поворяйте этого - это сделано в фотошопе ... ... ВОТ ...
(89) Шепот... родной город обязывает... ничего ровного. Если завод, то большего города, если гостиница, то самая бесполезная и высокая в городе, если легковушка, то меньше всех...
Магия, не магия, но из малого произрастает большое.... Современные компьтеры расхолаживают программистов позволяя не задумаваться об оптимизации кода и экономии памяти. В результате получаем расчет себестоимости и корректировку стоимости списания по 6 часов... Перешли для получения нового функционала и получения аналитики - но плата за это - длительность не очень сложных расчетов. Вот проблема на самом деле.
(90) Вспомнился 1986г . Оперативная память для бортовой БЦВМ измерялась Кб и суровой ниткой делилась между разработчиками различных систем.
Требовалась жесточайшая экономность кода. Эти Кб занимали , обменивали , одалживали до след. проекта и т.д. Началась антиалкогольная компания и Кб обменивали на бутылки.
(70) Можно не коверкать? Вы банально не уважаете своих собеседников. Здесь не миста.
(74) 120 гигов, пустое хранилище, база за 4 года, по 10 тыс документов реализации в месяц. Так понятнее? Куча виртуальных таблиц - это реализация алгоритма. Если его понять, остальное - тут же становится ясно. Я и не надеялся, что кто-то без разъяснений алгоритма разберется (хотя нашелся как минимум 1 человек, который разобрался без моих дополнительных объяснений). З.Ы. Сейчас я не буду впадать в полемику. Хочу отдохнуть на выходных
81.
Шёпот теней
1786
29.11.09 09:43
Сейчас в теме
(79), (80) ... удивили ...
... выбран слишком простой демагогический приЁм, чтобы увести разговор от конкретного примера в сторону красоты "филосовской" сложности ... ... уверен, я не провоцирую, Eugeneer вас "отметелит" сложной философской простотой - "бритвы Оккаямы" ... ... вОООт ... п.с. «Бритва (лезвие) О́ккама» — методологический принцип, получивший название по имени английского монаха-францисканца, философа-номиналиста Уильяма Оккама (Ockham, Ockam, Occam; ок. 1285—1349). В упрощенном виде он гласит: «Не следует множить сущее без необходимости» ...
77.
Шёпот теней
1786
28.11.09 20:35
Сейчас в теме
нет Ish_2 ... не ответишь ... не позднее ... и никогда ... не сможешь ...
... порвЁт тебя Eugeneer как тузик грелку ... ... и хорошо ... может чего-нибудь и надумаешь ... ... вот ... без злорадства но с надеждой ...
(82) Никуда я не увожу, я просто сокращаю свой пост за счет емкого понятия на уровне 1го курса института. Все рассуждения Eugeneer можно свести именно к Бритве Оккама - не плодить сущностей без надобности или усложнять сверх необходимости. Ключевые слова здесь "надобности" и "необходимости". Кроме того, он абсолютизирует свой опыт и считает, что проблемы больших объемов данных надуманны. Мой пост относился именно к нему, а не к тебе, Шепот.
С тобой всё по другому. Я никак не могу понять, что тебе надо. То ты просишь раскрыть механику оптимизатора запросов SQL - а это теория, т.к. для каждой базы всё будет по-разному. То ты заявляешь, что тебе нужна конкретика - покажите запрос. То ты пишешь пост в стиле "дао программирования". И всех обвиняешь в увиливании...Никто с темы слезть не пытается. Просто люди по-разному воспринимают проблему: кто-то конкретно запрос на дебиторку, кто-то запрос с нарастающими итогами, кто-то преимущества разных вариантов сочетания запросов и кода, а кто-то вообще не видит проблемы. Одно твое желание я знаю точно - расшевелить болото.
83.
Шёпот теней
1786
29.11.09 10:57
Сейчас в теме
(82) ... то ли побил ... то ли похвалил ... то ли ...
... но ткнул понятием 1 курса ... ещЁ один демАгоический приЁм ... ... прям как у М.Жванецкого "... что может сказать хромой об исскустве Герберта Фон Караяна, если ему сразу сказать что ОН хромой ..." ... ... значИтельность не может быть больше знАчимости ... ... вот ...
85.
Шёпот теней
1786
29.11.09 13:33
Сейчас в теме
I_G_O_R ... хм ...
1. уважаю ваше мнение ... 2. мне хочется знать то чего не знаю, в чём сомневаюсь, то что хочу знать ещё лучше ... 3. методы получения знаний могут быть разные ... но когда на конкретный вопрос о 2*3 тебе начинают говорить об "ИНТЕГРАЛЬНЫХ МЕТОДОВ ДЕТЕРМИНИРОВАННОГО ФАКТОРНОГО АНАЛИЗА" поневоле начинаешь задумываться ... так ли нужна сложность интеграла в получении утроенного сложения ... такая вот дЕмагогия ... ... вот ...
95.
Шёпот теней
1786
02.12.09 12:47
Сейчас в теме
... почти в тему по поводу идексирования : ...
... почти в тему но не совсем : ... ...вот ... ...
(95) Несколько не то. То что выборка у таблицы с индексом будет осуществляться быстрее - само собой.
Но если мы только получили временную таблицу - индекс у нее отсутствует. Оптимизатор запроса или мы явно должны ее индексировать ? Я не нахожу большой разницы . Артур считает , что надежнее всё-таки явно её проиндексировать. Автор:
Подписаться
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора. Публикация:
№ 61295 Создание 25.11.09 09:32 Обновление 07.12.09 00:00 Статистика:
Просмотры 58114 Загрузки 430
Рейтинг
118 Комментарии 125 Характеристики:
Код открыт Не указано Рубрики Математика и алгоритмы Запросы Кому Программист Тип файла Конфигурация (md, cf) Платформа 1С:Предприятие 8 Конфигурация 1C:Бухгалтерия Операционная система Не имеет значения Страна Россия Отрасль Не имеет значения Налоги Не имеет значения Вид учета Не имеет значения Доступ к файлу Бесплатно (free) |