Есть таблица со списком клиентов.
Есть довольно сложный алгоритм определения, является ли клиент действующим или не действующим.
Я могу на любой момент определить количество действующих абонентов.
И мне нужно составить таблицу со следующими полями: дата, количество на начало периода, приток, отток, количество на конец периода. Количество на конец периода, естественно, должно совпадать с количеством на начало следующего периода.
А вот с притоком и оттоком сложнее. Самый простой вариант это посчитать разницу между количеством на конец и начало периода, положительную разницу записать в приток, отрицательную разницу записать в отток. Но это не совсем точно, поскольку мне хотелось бы видеть приток и отток отдельно.

На тестовом наборе данных я обкатал два варианта учета.
Но на рабочей базе объем данных на 4 порядка больше, поэтому хотелось бы спросить предварительно совета.

1 вариант - если упрощенно, то я фиксирую во вспомогательной таблице статус клиента (действующий/недействующий) на каждую дату, а затем делаю два джойна с календарем и с помощью группировки определяю приток и отток:


Скрипт запускался на рабочей базе, считает точно и даже не очень долго (быстрее, чем я ожидал), но мне не нравится его идея — у меня порядка 10к клиентов и эти 10к записей нужно соединять с каждым днем календаря, а затем снова группировать по дням. Например при выполнении посуточного отчета за 6 лет во вспомогательной таблице будет почти 30кк записей, которые затем нужно будет сгруппировать.

2 вариант я на рабочей базе пока не запускал, но его идея другая. Я на каждый день считаю количество действующих клиентов и количество недействующих клиентов. Затем выполняю второй запрос с аналитикой и вычисляю отток (разница по количеству недействующих клиентов между следующим и текущим периодом) и вычисляю приток (разница между количеством действующих клиентов плюс отток).
Запрос получится примерно такой:


Выглядит мой взгляд лучше, но мне не нравится case...end в выражении группировки, он будет достаточно сложным.

________________________
Мы смотрим с оптимизмом...
...в оптический прицел.

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

Почитал про SCD.
В теории это наверное было бы лучшим решением.
В используемой информационной системе для ряда параметров используется тип 2.
Но для параметров, от которых зависит действительность/недействительность клиента, изменение значений не фиксируется, а модификация информационной системы слишком сложна.

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

Alibek B.2 вариант я на рабочей базе пока не запускал
Запустил, отлично работает, гораздо быстрее первого варианта. И насколько я проверил, считает точно.
К сожалению реальная задача у меня чуть более сложная, клиенты дополнительно распределены по группам и мне нужно считать динамику в разрезе групп. А сложность в том, что есть специальная группа для отключаемых клиентов, куда они перемещаются перед отключением, и в результате отток учитывается именно в этой специальной группе.