The problem with the timestamp is that it keeps people from thinking that they've got an enum.
For example, let's start with an object, which has a boolean flag "active".
boolean is_active;
We will always want to get a bit more advanced, and get into sub-states as it is brought up. We can't do that with a boolean. So we go to an enum.
Enum current_state {
not_configured;
being_provisioned;
active;
disabled;
deleted;
}
current_state state;
We have an enum in hiding. Converting the boolean to a timestamp stops the conversion to an enum - we can't overload the presence of a timestamp into the multiple values in the enum.
The timestamp is "what happened, when", an audit log/change history function. That should be kept separate from the rest of the database.
Sometimes, there is a business reason to track a timestamp - charge the customer 30days after the item became "active". How to model that depends on your database and what is required - history table, convert the enum to struct, time_became_active, time_of_last_state_change, etc.
For example, let's start with an object, which has a boolean flag "active".
boolean is_active;
We will always want to get a bit more advanced, and get into sub-states as it is brought up. We can't do that with a boolean. So we go to an enum.
Enum current_state { not_configured; being_provisioned; active; disabled; deleted; }
current_state state;
We have an enum in hiding. Converting the boolean to a timestamp stops the conversion to an enum - we can't overload the presence of a timestamp into the multiple values in the enum.
The timestamp is "what happened, when", an audit log/change history function. That should be kept separate from the rest of the database.
Sometimes, there is a business reason to track a timestamp - charge the customer 30days after the item became "active". How to model that depends on your database and what is required - history table, convert the enum to struct, time_became_active, time_of_last_state_change, etc.