Семь строк в SQL — ещё не семь дней. Как пропуски дат меняют скользящую сумму
Для показателя «за последние семь дней» легко написать:
SUM(amount) OVER ( ORDER BY day ROWS BETWEEN 6 PRECEDING AND CURRENT ROW )
Но ROWS отсчитывает строки. Если в таблице нет дней без продаж, семь соседних строк могут охватывать несколько недель.
Проверим на учебном примере для SQLite. В таблице одна строка на день с продажами; в остальные дни продаж действительно не было. Суммы для простоты записаны в рублях.
WITH daily(day, amount) AS ( VALUES ('2026-10-01', 10), ('2026-10-09', 20), ('2026-10-10', 30) ) SELECT day, SUM(amount) OVER ( ORDER BY day ROWS BETWEEN 6 PRECEDING AND CURRENT ROW ) AS sum_by_rows, SUM(amount) OVER ( ORDER BY julianday(day) RANGE BETWEEN 6 PRECEDING AND CURRENT ROW ) AS sum_by_days FROM daily ORDER BY day;
Результат:
Для 10 октября нужный период — с 4 по 10 октября включительно. Продажа 1 октября в него не входит, поэтому сумма равна 50. Окно по строкам захватывает все три имеющиеся записи и возвращает 60.
В варианте с RANGE функция julianday(day) даёт числовую шкалу дней. Граница 6 PRECEDING охватывает текущий день и шесть предыдущих. Здесь используются корректные даты без времени; для временных меток сначала нужно определить часовой пояс отчёта и получить дневные итоги.
Есть и второй способ: дополнить таблицу календарём, чтобы каждому дню соответствовала строка, а подтверждённому отсутствию продаж — ноль. Тогда ROWS снова будет отсчитывать дни. Это также позволит показать на графике даты без продаж.
Для средней за семь календарных дней различие ещё заметнее. Если в том же семидневном окне заменить SUM(amount) на AVG(amount), на 10 октября получится 25 ₽: среднее по двум строкам за 9 и 10 октября. А среднее за все семь календарных дней — 50 / 7 ≈ 7,14 ₽. Этот расчёт предполагает, что данные за все семь дней полные. Для сравнения: обычный AVG(amount) по всей исходной таблице дал бы 20 ₽.
RANGE ограничивает окно, но не создаёт строки для пропущенных дат. Поэтому и в результате запроса остаются только даты, которые есть во входных данных.
Отсутствие строки из-за сбоя загрузки нельзя автоматически приравнивать к нулевым продажам. Иначе календарь сделает результат аккуратным, но неверным.
Перед проверкой формулы по идее надо проверить, что означает одна строка таблицы. Для скользящих показателей это напрямую определяет границы расчёта.
