> A lot of boolean data is representing a temporal event having happened. For example, websites often have you confirm your email. This may be stored as a boolean column, is_confirmed, in the database. It makes a lot of sense.
> But, you're throwing away data: when the confirmation happened. You can instead store when the user confirmed their email in a nullable column. You can still get the same information by checking whether the column is null. But you also get richer data for other purposes.
So the Boolean should be something else + NULL?
Now we have another problem ...
It should be: std::optional<Timestamp> (or Optional[datetime] or equivalent in others languages)
If you're using a type system that is so poor that it won't easily detect statically places where you're not correctly handling the absent values, you do have a much bigger problem than using bool.
It should be a timestamp of the last time the email was verified.
It's a surprisingly useful piece of data to have.
Even more useful is a log of all the changes in the database. This gives you what you want, and it would be automatic for any data you store.
So, keep the Boolean, and use a log.
No? So you have to look at database history to extract information you think is useful?
That's a terrible database design.
It's the basis behind Datomic, if I'm not mistaking.
You can easily search through history. The point is, it is better to do this in the design of the database than in the design of the schema.
So: "No?" -> "Yes!"
Okay, but for something like SQL this seems like a bad idea.