В какой базе данных лучше всего хранить данные для дашбордов?

Question

[Asfli]

Всем привет! Необходимо автоматизировать сбор табличках данных из excel и сделать вебморду с дашбордами, в которых записи будут суммироваться, вычитаться, показывать накопительный итог и строить графики.
Структура столбцов таблицы следующая --> | дата(ежедневный отчет) | пришло | ушло | итог=вчерашний итог+пришло-ушло.
То есть итог будет зависеть от предыдущего дня и так до начала таблицы. Главная загвоздка, что excel легко пересчитает все значения, если я изменю итог 1 дня месяца в конце месяца, а что делать с реляционной бд? Или есть другие механизмы, как оптимально хранить такие связанные данные на сервере?

Comments

[Akina]

Или есть другие механизмы, как оптимально хранить такие связанные данные на сервере?

Это НЕ связанные данные.

В какой базе данных лучше всего хранить данные для дашбордов?

В любой. Что лучше знаешь, то и используй.

Answer 1

[Akina]

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

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

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

Comments

[Asfli]

Спасибо, наверное действительно не стоит хранить вычисляемые данные. А самые частые запросы "запечь" в виде кэша

Answer 2

[mayton2019]

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

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

Comments

[Akina]

Он ведь не меняется? Верно?

Ну как бы автор в открытой и явной форме говорит совершенно противоположное:

excel легко пересчитает все значения, если я изменю итог 1 дня месяца в конце месяца

То есть корректировка предыдущих данных - штатное событие.

[mayton2019]

Akina, ну дашборд за 1 день дернут 1000 раз по вебу. И один раз в день может быть чего-то
подкорректируют.

Как видите, обсуждение архитектуры - не всегда вещь всем очевидная. Это как - яблоки и груши.

[Akina]

Ммм... предрасчётная материализация плюс рефреш по триггеру?

[mayton2019]

Akina, ну да. И если грамотно использовать NGINX то материализацию отчета можно делегировать ему.
Я-бы добавил хедеры "If-Modified/NonModified-SInce" чтоб перерасчет происходил по событию.

[Asfli]

Спасибо. Изменение конечно самый тяжелый по производительности вариант, но он возможен. Вытащить наиболее частые запросы в статичную форму мне идея нравится

Answer 3

[alexalexes]

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

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

Comments

[Asfli]

Спасибо за развернутый ответ!