Почему `SUM() OVER (ORDER BY ...)` иногда считает «неправильно»: разбираем оконные фреймы в SQL

[Viktor006Juk]

Чувствуется настоящий ресерч уровня "гуглил три часа, понял на полстраницы". Но зато честно - половина реальной разработки так и выглядит.

[rozhnev]

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

[Akina]

Есть ещё один способ на реальных данных получить детерминированные накопительные/скользящие итоги, и при этом не прибегать к использованию определения фрейма (для накопительных). Всё, что нужно - просто расширить условие сортировки и сделать ключ сортировки уникальным. Т.е., например, вместо SUM(amount) OVER (ORDER BY amount) пишем SUM(amount) OVER (ORDER BY amount, {id}) , где {id} есть некое уникальное поле либо выражение (ничего подходящего нет в первых мини-примерах статьи, но я не зря оговорился о реальных данных) - и имеем нормальный детерминированный результат.

Причём на сей раз - стопроцентно и гарантированно детерминированный. В отличие от ROWS - там пусть и считаются отдельные записи, но сортировка -то уникальности не обеспечила, а потому порядок записей с равным ключом сортировки в группе не определён, и кто ведает, что нам из той группы отсчитается.

[rozhnev]

Спасибо за хороший пример. Запомню для дальнейшего использования.

[windsurfer69]

Пишите еще, не слушайте недоброжелателей. Статья полезная.

[rozhnev]

Спасибо, обязательно напишу. Кстати я не заметил недоброжелательности. Пока вся критика конструктивная.

[OchirD]

Прохожу курс аналитики, странно что такой инфы там нет)
Статья отличная, все по полочкам, все понятно!
Сохраню ссылку в свой банк знаний)