@immelnikoff
Изучаю БД. Пока больше спрашиваю, чем отвечаю

Как реализоваться подход CQRS + Event Sourcing для логирования изменений БД пользователями приложения?

В продолжение моего предыдущего вопроса: Разрешить в таблице только INSERT с целью логирова...
В предыдущем моем вопросе Иван Шумов посоветовал мне организовать логирование в БД с помощью подхода CQRS + Event Sourcing.
Пытаюсь это как-то осмыслить на своем рабочем примере.
Имеется таблица Schedule_test, содержащая актуальное расписание вкл/выкл уличного освещения для каждого города. Изменять расписания могут энергетики (каждый – в своём городе). Задача логировать все изменения данной таблицы, производимыми пользователями (энергетиков). Пользователь может добавить расписание на новую дату (INSERT), изменить (UPDATE) или удалить (DELETE). То есть нужно регистрировать эти три события.
На ум приходит только такая схема:
5db6bf05b140f364795739.png.
Но это явно что-то не то. Кроме того, не понятно, что делать с удаленными записями в Schedule_test. На них же продолжают ссылаться записи из Schedule_test_Log...
Нужна подсказка.
  • Вопрос задан
  • 104 просмотра
Решения вопроса 1
inoise
@inoise
Solution Architect, AWS Certified, Serverless
Это работает несколько не так. Events logging работает как сохранение таких данных как:
- уникальный идентификатор события
- имя события
- версия события (со временем обработчик может меняться)
- данные события
- опционально уникальный идентификатор сущности (но так делают не часто)

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы