Asfli

В реляционной базе - основная таблица - это лог событий.
event_log:
event_id - идентификатор события
event_date - дата и время события
event_type_id - тип события (пришло или ушло)
value - сколько (пришло или ушло, положительное значение)
А чтобы подготовить данные для визуализации, переводите лог в агрегированный вид:
либо делаете view на основе запроса, либо делаете хранимую процедуру для генерации агрегированных данных и кладете их в отдельную таблицу:
daily_statistics:
id - идентификатор агрегированной точки
stat_date - дата агрегированной точки
in_value - пришло (кол-во)
out_value - ушло (кол-во)
current_value - баланс

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

Вы можете материализовывать дашборд. Тоесть фактичекски делать его хард-копию.
Он ведь не меняется? Верно? И отдавать статический html.

А в базе - отслеживать бухгалтерию вот как предлагали уже.

а что делать с реляционной бд

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

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