Every change you can make in a database becomes an event by this definition. It's just as useful to know when every change happens in your database, and by who.

Every change you can make in a database becomes an event by this definition. It's just as useful to know when every change happens in your database, and by who. Which is why we have `audit' logs. Usually online logs that can recover every change over the entire history of a database, every row having a versioned history of what changed by who. By keeping it separate, not only does it make domain modelling and intuitive use more logical, it makes primary query performance dramatically better. And if logically you want to treat them as events, they should be in a chronological events table by themselves, not as an overloaded nullable field. To distill what I've said above, as politely as possible I will say that if you model a boolean as a timestamp, you are covering up for other much larger problems.