best event sourcing db strategy

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

Solution is the db structure where you create only one generic table, and save the events as serialized string to one column

This is by far the best approach as replaying events is simpler. Now my two cents on event sourcing: It is a great pattern, but you should be careful because not everything is as simple as it seems. In a system I was working on we saved the stream of events per aggregate but we still had a set of normalized tables, because we just could not accept that in order to get the latest state of an object we would have to run all the events (snapshots help but are not a perfect solution). So yes event sourcing is a fine pattern, it gives you a complete versioning of your entities and a full auditing log, and it should be used just for that, not as a replacement of a set of normalized tables, but this is just my two cents.