The idea of event sourcing is a little different. Each change in the current state of your database would be a new event in a stream that only allows inclusion. Each update on the table would generate a new line, the change of status. If you have changed to an incorrect status, a new line would be generated by correcting this status. So, we'd have all the changes until you reach the current time of permission for the user.
From the beginning, in the status_user table using the concept of event sourcing, the records would be as follows:
|
ID |
user_name |
status |
user_manager |
|
1 |
John Doe |
admin |
Manager1 |
|
1 |
John Doe |
normal_user |
Manager2 |
If a new status change is applied to the user John Doe, a new line would be generated by keeping track of the changes. Event sourcing uses the append only model for database records.
Event sourcing has positives and negatives. Among the positive points are the historical maintenance records, while negatives include exponential growth in the database records' editing operations. For this reason, it is very common to see event sourcing being used with CQRS, precisely, not to encumber the searches in the database due to a large number of the same record.