3 ms·
I would recommend going full event sourcing if you're going to put in that kind of effort into preserving history. Assuming you don't need real time access to
by codr7 2y ago
I would recommend going full event sourcing if you're going to put in that kind of effort into preserving history.
Assuming you don't need real time access to data from several points in time, that is.
Just store the events with timestamps and json in a separate table, I usually build a hierarchy with parent event refs to simplify auditing.
As an added bonus, the app is now completely command driven.
Getting historic data for a specific point in time means starting with an empty database and replaying earlier events, alternatively storing undo information in events.
- mananaysiempre 2y agoWhat about Apache Samza[1], which is specifically built to maintain database-shaped views on top of event logs—do people run it? Or is the infra overhead from it requiring Kafka and a Java runtime and so on too much? [1] https://samza.apache.org/ https://samza.apache.org/
- codr7 2y agoNo experience. But the thing is, I usually already have a perfectly capable database, any extra infra better pull its weight and then some.