best event sourcing db strategy

Question

I want to setup a small event sourcing lib. I read a few tutorials online, everything understood so far.

The only problem is, in these different tutorials, there are

Answer 1

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.