Information
- Rating
- Does not participate
- Location
- Россия
- Date of birth
- Registered
- Activity
Specialization
Бэкенд разработчик
Старший
From 6,500 $
ASP.NET WEB API
Entity framework
RabbitMQ
Redis
Apache Kafka
Elasticsearch
Docker
Английский язык
SQL
.NET
Но доделанное с left join и union all.
Добавлена индексированная вьюха TurnoverMonth.
Если кому особо надо, берите и сравнивайте что вам будет быстрее.
Может abkurenkov стоит это скопировать в статью.
Баланс это остаток на какой то момент времени.
У автора балансы есть только в запросах, в которых не используется between.
Во вьюхе TurnoverHour нет остатков, а только обороты за месяц.
Автор забыл в итоговом запросе посчитать все обороты с начала времен.
Вот это условие, всё поломало, превратив Остатки в обороты за период:
Сумма оборотов за период НЕ РАВНА сумме оборотов с начала времен.
Только сумма оборотов с начала времен является остатокм.
Я утверждаю что тут нет итогового правильного запроса.
Автор разбил задачи, но НЕ объединил их. (или сделал это неправильно)
Нужно просуммировать всё в TurnoverHour, с начала времен до начала месяца (не включая начало месяца), а затем, накопительно проссумировать всё, от начала месяца, до даты меньшей чем finish+1 (включая начало месяца)
Лучше так: «dt < „2015-01-04“», то есть, строго меньше следующего дня
У меня индекс такой:
появилась сортировка
а значит имеет значение порядок в partition by
union all или left outer join в помощь
2015-02-01 00:00:00.000
что наоборот то?
При наличии where productID in эта манипуляция должна ускорить выборку
В данном примере уместен порядок полей в индексе productId, StorehouseID, Dt.
По моему у автора итоговый запрос абсолютно неправильный, так как не выдает остатков.
dbo.TurnoverHour у нас не содержит остатков на начало месяца, оно содержит дельту за определенный час
select
dt,
StorehouseID,
ProductId,
Quantity,
sum(Quantity) over
(
partition by StorehouseID, ProductID
order by dt
) as Balance
from dbo.TurnoverHour with(noexpand)
where dt between start_month and finish
выдаст накопительную сумму изменений, от нулевого остатка на начало месяца до момента finish
мне кажется где то не хватает UNION ALL текущего запроса с остатками на начало месяца
получаю select @start_month; = 2015-02-21 00:00:00.000
это нормально?
если productId в начале, то это ускорит поиск по индексу, для набора товаров, а не для всех товаров в таблице.
Если же первым будет StorehouseID у которого плохая селективность, то конечно подходящего индекса для особого ускорения не будет.