275
Рейтинг

randomus



  •   Регистрация: 05.09.2019 (4 года назад)

  •   Был(а) на сайте: 02.04.2024

Друзья
  • Дмитрий Петров
  • Осипов Сергей
  • Дмитрий Малышев
  • Юлия Толстых
Подписчики 13
Группы

Профессиональный разработчик

Рейтинг 275

Последний раз про срез последних (на каждую дату в запросе)
+171 –

Статья Программист Стажер Платформа 1С v8.3 Запросы MS SQL Бесплатно (free) Нет файла Запросы

Срез последних на каждую дату в запросе. Известные факты о задаче: часто встречается на испытаниях соискателей на работу программистом 1с, постоянно провоцирует споры об оптимальном решении. В данном тексте приводятся замеры производительности различных вариантов решения задачи.

15.02.2021    57921    randomus    47       

171

Treemapping. Демонстрационная обработка
+30 –

Инструменты и обработки Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m) Внешняя обработка (ert,epf) Математика и алгоритмы Работа с интерфейсом

Пример реализации диаграммы вида Treemap на 1С

1 стартмани

27.02.2020    9441    22    randomus    4       

30

Treemapping — способ визуализации данных древовидной структуры. Карта-схема дерева
+77 –

Статья Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free) Нет файла Математика и алгоритмы Работа с интерфейсом

Предлагается ознакомиться с редким способом графического представления иерархических данных. Приводится алгоритм формирования и пример реализации.

18.02.2020    9613    randomus    20       

77
Смотреть все

Комментарии

Dev › Последний раз про срез последних (на каждую дату в запросе) › #44 23.02.21 22:25
(25) Наконец дошли руки запустить эти запросы на первоначальном стенде.

Сразу только период 6 мес.:

1) 16 сек. - весьма неплохо. Но запрос не один - есть коррелированный.
2) 22.3 сек. - улучшенный мой (В) вариант, за счет доп. отбора в соединении.
3) 46.5 сек. - результат улучшен, математику оптимизировали.

Ну в общем, 2-й запрос удовлетворяет условиям конкурса.
Если других вариантов не будет, признаем его победителем.

Отмечу, что 1-й запрос - очень элегантное решение, мне понравилось. По сути, 1-й и 2-й запрос делают одно и тоже, но во втором приходится перебрать гораздо больше строк. И исправить без коррелированного запроса никак не получается. @ildarovich - отдельное спасибо за дельные комментарии.
Dev › Последний раз про срез последних (на каждую дату в запросе) › #42 19.02.21 12:57
(38) Извините, неправильно понял вас. Если это результаты запросов из (25) то действительно интересно, есть над чем подумать, спасибо.
Dev › Последний раз про срез последних (на каждую дату в запросе) › #41 19.02.21 12:49
(37) Согласен на ваши условия. Попробуйте.

Вообще, конечно, я согласен - мое исследование однобокое и неполное - границы применимости неплохо было бы определить.

Кстати, тот факт, что я отключил параллелизм, почему-то никто не отметил. Но в реалиях-то он есть, и какие-то запросы параллелятся лучше, какие-то хуже. Тоже надо исследовать, если по хорошему.

Тета-соединения в варианте Б меня тоже смущали, поэтому он и вызывал недоверие. Но, как ни странно, в моих условиях показал себя хорошо
Dev › Последний раз про срез последних (на каждую дату в запросе) › #35 18.02.21 11:07
(33)Всё правильно, так и было задумано. Потому что, в данном случае, достаточно индексов, которые 1с создает по умолчанию.
В гугле поиск "индексы 1с" первая ссылка.
Можно проверить средствами SQL сервера
Dev › Последний раз про срез последних (на каждую дату в запросе) › #32 18.02.21 10:01
(28) откуда я знаю как вы адаптировали "мои" запросы к реальной базе?

И что такое "много = 31 день" в "моем 3 запросе"?

Много - это в запросе Ильдаровича, и оно не в днях измеряется а в рублях.
и 31 в таком случае это не много и запрос вероятно работает не правильн.

Похоже, надо запрещать комментарии, а то холивар разгорается :)

Напишите свою статью лучше. Может я прочитаю и прояснится в голове
Dev › Последний раз про срез последних (на каждую дату в запросе) › #30 18.02.21 9:50
(27)
Цитата
установки цен могут (и идут!) каждый (рабочий, хотя бы) день
зачем тогда нужен срез последних?
Dev › Последний раз про срез последних (на каждую дату в запросе) › #29 18.02.21 9:48
(25)
Цитата
Нет, не так.

Все таки, настаиваю на своей формулировке :) Пока не получу реальный, а не фантазийный пример, когда "срезаемая" оценка некоей сущности на 2-3 порядка превосходит количество периодов среза.

Цитата
Кстати, а индексирование по измерению "Номенклатура" в регистре сведений "ЦеныНоменклатуры" когда и зачем было отключено? Ну или почему оно "ведущим" не было сделано? Я имею ввиду тестовую конфигурацию.

Я начинаю сомневаться в продуктивности дальнейшего спора.

Не было оно отключено. В регистре сведений по умолчанию создается кластерный индекс по всем измерениям по порядку следования в конфигураторе, а затем - по периоду.
Стыдно этого не знать, минус в коммент за это.

Я, кстати, пробовал индексировать поле Номенклатура отдельно - результаты немного ухудшались. Возможно, сервер тратил время на выбор нужного индекса.

Зря вы так переживаете за свой вариант, он красивый, и с этой точки зрения мне нравится больше остальных. Но это - вычислительный казус, упражнение для ума, а этот эксперимент не про хитрые приемы, а про скучную обыденность :)

Ваши варианты я попробую, сейчас тестового стенда нет под рукой. Но мне кажется - там только косметические улучшения
Dev › Последний раз про срез последних (на каждую дату в запросе) › #24 17.02.21 21:11
(21) В реальной жизни условная "переоценка" всегда реже условной "продажи".
Хотелось бы увидеть хоть один реальный обратный пример. Соответственно, мои выводы справедливы - в реальной жизни :)
Dev › Последний раз про срез последних (на каждую дату в запросе) › #20 17.02.21 15:28
(15) проверил :) оценки в плане запроса одинаковые, но время выполнения у первого варианта немного меньше
Dev › Последний раз про срез последних (на каждую дату в запросе) › #19 17.02.21 12:47
(15) думаю, что примерно одинаково. позже проверю