Да, скользящая средняя честно другой случай: там цена это бегущее состояние, которое пересчитывается на каждом приходе, и в оконки оно уже не ложится. Так что курсор тут разумный выбор, а не костыль. Спасибо, что поделились.
Спасибо, рад что зашло. По копейке: в самих цепочках округления нет, и копиться ему негде. Оно одно и в самом начале, когда суммы из источника приводятся к копейкам. Дальше накопительные итоги это суммы уже копеечных чисел, а длина пересечения это их разность, то есть снова ровная копейка. Финальный каст ничего не округляет, он просто подтверждает то, что и так в копейках.
Сходится потому, что куски одного списания это стыкующиеся подотрезки на одной оси: их длины по построению дают ровно длину списания. Длина цепочки тут не важна, длинная цепочка это просто больше точных вычитаний, а не больше накопленной ошибки. Нет ни одного шага, где сумму пришлось бы делить и потом округлять, поэтому и прятаться округлению негде.
Это исторически сложившаяся событийная модель: источник отдаёт события в JSON, чтобы схема могла гибко расширяться без частых изменений контрактов и жёсткой табличной структуры. Со временем может потребоваться больше аналитического контекста, и добавить такие данные в JSON обычно быстрее и проще. Да, для DWH это не самый оптимальный формат, поэтому дальше мы нормализуем события и приводим их к аналитической модели.
Да, соглашусь, часть терминов можно было подробнее расшифровать для внешнего читателя.
Если совсем упростить, у нас есть три события: бонусы начислили, бонусы потратили, либо бонусы сгорели по сроку жизни. Поэтому это не совсем два направления движения. Сгорание для нас тоже отдельное событие, потому что его нужно корректно отразить в учёте.
По второй части вы в целом правы: бонусы универсальны по расходованию. Пользователь не обязан тратить бонус, начисленный за одно действие, строго на ту же категорию действий. Но для финансового учёта нам всё равно нужно понимать, из какого начисления и в какой доле была закрыта каждая трата. Поэтому и появляется FIFO-сопоставление между начислениями, списаниями и сгораниями.
Да, скользящая средняя честно другой случай: там цена это бегущее состояние, которое пересчитывается на каждом приходе, и в оконки оно уже не ложится. Так что курсор тут разумный выбор, а не костыль. Спасибо, что поделились.
Спасибо, рад что зашло. По копейке: в самих цепочках округления нет, и копиться ему негде. Оно одно и в самом начале, когда суммы из источника приводятся к копейкам. Дальше накопительные итоги это суммы уже копеечных чисел, а длина пересечения это их разность, то есть снова ровная копейка. Финальный каст ничего не округляет, он просто подтверждает то, что и так в копейках.
Сходится потому, что куски одного списания это стыкующиеся подотрезки на одной оси: их длины по построению дают ровно длину списания. Длина цепочки тут не важна, длинная цепочка это просто больше точных вычитаний, а не больше накопленной ошибки. Нет ни одного шага, где сумму пришлось бы делить и потом округлять, поэтому и прятаться округлению негде.
Спасибо за комментарий!
Это исторически сложившаяся событийная модель: источник отдаёт события в JSON, чтобы схема могла гибко расширяться без частых изменений контрактов и жёсткой табличной структуры. Со временем может потребоваться больше аналитического контекста, и добавить такие данные в JSON обычно быстрее и проще. Да, для DWH это не самый оптимальный формат, поэтому дальше мы нормализуем события и приводим их к аналитической модели.
Спасибо за комментарий!
Да, соглашусь, часть терминов можно было подробнее расшифровать для внешнего читателя.
Если совсем упростить, у нас есть три события: бонусы начислили, бонусы потратили, либо бонусы сгорели по сроку жизни. Поэтому это не совсем два направления движения. Сгорание для нас тоже отдельное событие, потому что его нужно корректно отразить в учёте.
По второй части вы в целом правы: бонусы универсальны по расходованию. Пользователь не обязан тратить бонус, начисленный за одно действие, строго на ту же категорию действий. Но для финансового учёта нам всё равно нужно понимать, из какого начисления и в какой доле была закрыта каждая трата. Поэтому и появляется FIFO-сопоставление между начислениями, списаниями и сгораниями.