I want to setup an small event sourcing lib. I readed a few tutorials online, everything understood so far.
The only problem is, in this different tutorials, there are two different db strategies, but without any comments why they use the one they use.
So, I want to ask for your opinion. And important, why you would prefer the solution you choose.
Solution is the db structure where you create one table for each event.
Solution is the db structure where you create only one generic table, and save the events as serialized string to one column.
In both cases I'm not sure how they handle event changes, maybe they create a hole new one.
Best How To :
I built my own event sourcing lib and I opted for option 2 and here's why.
- You query the event stream by aggregate id not event type.
- Reproducing the events in order would be a pain if they are all in different tables
- It would make upgrading events a bit of pain
There is an argument to say you can store events on a per aggregate but that depends of the requirements of the project.
I do have some posts about how event streams are used that you may find helpful.
6 Code Smells With Your CQRS Events and How to Avoid Them
Aggregate Root – How to Build One for CQRS and Event Sourcing
How to Upgrade CQRS Events Without Busting Your Event Stream
I hope you find that useful.