как первая картинка или как вторая?
никак, у нас нет event sourcing-а
В сущность слева можно встроить jsonb DetailsJson { get; set; } с деталями события, а тип деталей можно выбирать в зависимости от EventType. Второй вариант выглядит, конечно, вкуснее, но там приходится писать много маппингов между базой и доменом.
@dopusteam а Вам известны СУБД с поддержкой полиморфизма на уровне хранилища данных?
А как это в базу сохранять? Причём в реляционную!
N таблиц под каждый тип события? Сомнительная перспектива!
а зачем это в базу сохранять?
https://habr.com/ru/company/otus/blog/518282/ https://habr.com/ru/articles/178259/
если ef юзаешь есть Table Per Hierarchy. единственное что много null сталбцов будет
хранить события в реляционной субд? окай...
есть разные стратегии еще. все в одной . общие в одной разные в разных . все в разных .
в этом прикол эвентсорсинга что бы на каждое действие сохранять событие которое привело систему к текущему состоянию. потом можно на пустой системе до определенного события выполнить все события и получить состояние системы на тот момент времени.
там ж замечание по поводу реляционной было, а не по поводу евентсорсинга
просто выше он спросил зачем это в базу сохранять.
"Общие в одной, разные в разных" Звучит интересно!
как варик еще можно json хранить если у тебя постгрес. но это такое себе конечно но варик рабочий)
Да, мы так делаем, храним EventType и jsonb Details. Здесь плохо то, что легко ошибиться и записать в базу неправильный тип или неправильный JSON. Но, действительно, это самый простой вариант.
Обсуждают сегодня