Большое спасибо что собрали самое важное в такое короткое видео)

@yellow_club

2 жыл бұрын

Да, спасибо Артёму за крутой материал

Полезное видео, спасибо. Интересно было бы посмотреть на все стандарты разработки, которые применяются Автором.

Спасибо. Появился вопрос на разделе "Ставить НЕ в условии не надо", но в конце видео ответили на него

@yellow_club

2 жыл бұрын

Да, меня это тоже смущало)

@Unfound3d

2 жыл бұрын

Я что-то не заметил. Ткните пальцем, где это аргументированно

в общем, sql в 1С и так бедный, вы ещё и отменили половину sql😅

На файловой базе выборка из 30к позиций по условию к перечислению через где и виртуальной таблице составило 3 сек. В пользу виртуальной таблицы. а вот по 2 значениям перечисления через где на 2 секунды быстрее отработало.

В целом я не против использовать небольшие ВТ вместо В, НЕ и пр. НО, как быть с СКД, где юзер ставит произвольные фильтры. Писать движок (функцию), который в скомпонованный макет поменяет текст запроса (не помню, текст(ы) запросов в скомпонованном макете доступны на запись)?

@maximgunchenko3754

2 жыл бұрын

В модуле объекта в событии при формировании результата можно подменить текст запроса

Это не типовые ошибки в запросах. Запрос оптимален для решения задачи клиента. Оптимизация это уже второй этап за который нужно отдельно платить. И который может никогда и не наступить.

@yellow_club

2 жыл бұрын

Можно и так. Такой подход похож на внедрение. Сделаем как умеем, а дальше видно будет. Когда сидишь на сопровождении, то будешь больше думать об оптимизации

@olegshpilevoy

2 жыл бұрын

@@yellow_club Вот и готовая тема для ролика. Пригласить фрилансера или разраба из франча которые работают с разными клиентами и задачами в режиме "многозадачности".

@yellow_club

2 жыл бұрын

Хорошая тема, спасибо. Попробую организовать

А вЫ не думали, что чрезмерное использование временных таблиц и их индексация приведет (в большинстве случаев) к гораздо большим просадкам производительности исполнения запросов? ВТ нужно создать, потом еще индекс(ы) построить. Это весьма не маленькие операции. И приоритет должен быть на стороне читаемости, а не максимальной производительности (без фанатизма), пока код пишут люди.

@PupaVaskin

2 жыл бұрын

Первый запрос не решает поставленную задачу по критерию времени, потому читаемостью приходится жертвовать. Ну и цифры по времени приведены, было 10 сек, стало 0.5, видимо не так велики накладные расходы на ВТ.

Артем по ходу дела не пробовал профайлер запустить и глазками своими собственными посмотреть план. Трахать SQL-сервер менеджментом временных таблиц только чтобы уйти от В() - это настолько кринжово, что... Ну я даже не знаю что сказать... Куда выложить скрины запросов и профайлера? Вот прям взял и накидал два совершенно идентичных представленным запроса по своей довольно большой таблице документов. Второй вариант с внутренними соединениями очевидно же порождает несколько нестед лупсов в отличие от ни одного (максимум одного, если индексы совсем плохие) в первом запросе. Единственная неоптимальность в первом запросе - это использование НАЧАЛОПЕРИОДА/КОНЕЦПЕРИОДА, потому что это не позволяет использовать индексацию документа по дате. На сём и надо было остановиться, а не городить огород. Насчет цифр - первый запрос с исправленным МЕЖДУ у меня CPU:15, Reads:5096, Dura:24. Второй - CPU:47, Reads:40802, Dura:45.

6:41 Не верно, ТипЗначения() = Тип() и Ссылка в скуле получается полностью идентичный код. Вот собственно условие: T1.RecorderTRef = 0x0000019E (в обоих случаях), Запросы полностью идентичны (скулевые). Я не сомневаюсь что Вы хороший программист и умеете писать запросы оптимальные, но Вы хоть проверяйте информацию!!!

@andreykot7577

2 жыл бұрын

Это из той же серии что и Не Есть Null и Есть Не Null. Зачем тратить ресурсы когда можно сразу написать код преобразования. Вместо вызова двух функций быстрее вызвать одну.

НЕ (шаг = значение()) это отрицание булевого значения?

Типзначения() разве не использует индексированную физическую колонку с типом?

@Skarbovoy

2 жыл бұрын

Типзначения = тип и ссылка генерят одинаковый SQL код, но ссылка не работает на несовместимых типов.

Странно. Я читал, что оператор В как раз норм по производительности, потому что вьіполняется как запрос с обьединением. Бьіла рекомендация ИЛИ заменять на В. Может в исходном запросе достаточно бьіло последнее заменить на В из предвіьборки?

Индексирование булево полей мне кажется это гениально сказано (нет).

Очень много фантазий у ментора. Например передает запросы в планировщик(С точки зрения СУБД, 1С передает не запрос, а инструкцию. Инструкция подает в ОПТИМИЗАТОР. ОПТИМИЗАТОР в свою очереднь делает несколько планов запросов и подбирает оптимальный). По поводу быстродействия запросов , автор упоминул статистику(надо добавить еще КЭШЬ субд), так вот если вы не обновляете статисктику и КЭШЬ (либо не реструктаризируете таблицы БД), то конечно же, стандартизированные запросы будут выполняться быстрее. По поводу индексации ВТ это мрак(ВТ хранятся в оперативной памяти) и если вы их индексируете то из оперативки Вт попадает на хард, есть только один случай индексации ВТ, а именно когда ВТ > 8 мбайт(Потому что если ВТ > 8 мбайт то она всегда помещается из оперативки в хард). Буду сильно удивлен если у ментора есть серт Эксперта.

А чем плохо применение отрицания для булевых значений? Никаких неявных соединений там не будет

Если документов много миллиардов и нужно их анализировать, разве не лучше делать регистры, записывать туда предрасчетную информацию(даже хотябы регламентным заданием), индексируй. А потом запросы по уже подготовленным данным...

99% никакой оптимизации не делают. И в 99% она и нафиг не нужна

главная ошибка, это использование 1с как языка. каждый пишет шо хочет и в итоге получилась солянка.

@yellow_club

2 жыл бұрын

А в других языках разве не так же? Везде каждый пишет шо хочет