Как решить задачу:
1. Есть база данных postgreSQL которая содержит список учеников и их оценки (загружаются туда из CRM) а так же проведенные часы за занятиями на текущий момент
2. Есть Grafana которая выводит актуальные данные на текущий день
3. Проблема в том что по специфике работы с CRM иногда данные могут поменяться задним числом (например оценка поменяться в меньшую сторону или количество часов в большую - если это происходит в пределах текущего дня то ничего страшного, но если происходит в пределах предыдущего дня то такие данные не подходят )
Требуется в конце каждого дня "замораживать данные" за каждый пройденный день, - не думаю что на стороне графаны есть такой функционал , как лучше всего реализовать такой механизм ?
Например если делать еще 1 БД в которой будут храниться суммы данных за предыдущий день - то в графане придется делать 2 дашбоарда - актуальный и архивный - чего хотелось бы избежать
Требуется в конце каждого дня "замораживать данные" за каждый пройденный день
Если надо замораживать только срез данных на конец дня, то лучше копировать этот срез в отдельную таблицу.
Если надо сохранять состояние всего массива данных, то поможет только timeline (т.е. данные только добавляются, никаких изменений и удалений).
ссылку на пример дать не могу(думаю не проблема поискать), но суть вот в чем, в тригере на изменение проверяете, если текущая дата уже перешла за период в 1 сутки(как в ТЗ), то либо игнорьте, либо бросайте исключение, в противном случае делайте UPDATE, так гарантированно данные можно править только в течение заданного периода(1 сутки), вариантов что делать с другими данными(изменениями можете придумать сами, к примеру вести журнал и спрашивать с пользователей за их не своевременные исправления).
Такую задачу лучше всего решать на прикладном уровне. Тоесть создать таблицу аудита учеников и оценок.
Любое изменение основных таблиц - аудируется и потом только пишется в основные таблицы.
Потом по аудиту легко восстановить состояние таблицы в прошлом.
Некоторые DBMS (Oracle) содержат поддержку ретроспективных запросов которые позволяют
взглянуть на таблицу в прошлом (SELECT .... AS OF ....).
Некоторые средста Bigdata (Delta Tables) называют эту фичу time travel.. Синтаксис аналогичен
Оракловому. Глубина хранения истории обычно задается в настройках таблицы (retention).
Насчет Postgresql - не знаю. Надо читать документацию.
Средний
