Only really makes any sense for flags that go from false to true and don’t go back often. And even then it has huge semantic cost. How do you distinguish a “boolean timestamp” from an actual timestamp? Is “modified at” a flag indicating a pending modification or a timestamp when it was last modified?
Much better to just have two columns, so e.g. you can see “enabled” and an 'enabled_date" that indicates when you last enabled/disabled the entity.
Much better to just have two columns, so e.g. you can see “enabled” and an 'enabled_date" that indicates when you last enabled/disabled the entity.
That sounds good until you realize you now have two sources of truth, do you trust enabled or enabled_date? If you really want to go this route enabled should be a virtual field that checks enabled_date in the background so you can have the boolean semantics but still keep a single field.
I also used booleans a lot previously but since using Laravel I have come to enjoy the updated_at, created_at and deleted_at fields that it automatically creates and I follow this format as well now if I need more.
But if it can be disabled we’d also need a disabled_date, however this implies that the state can switch from enabled to disabled and vice versa an infinite number of time, so we should create n*2 fields (enabled_date_1, disabled_date_1, …, enabled_date_n, disabled_date_n) where n is the maximum amount of state switches/2. Of course we’ll have to implement stream logging of events into a database, or at least some sort of counter, to determine the value of n, and then dynamically create new fields as needed.
Problem solved!
I think having an enabled_at field as nullable timestamp is enough.
If it’s present, it’s enabled. If it’s null, it’s disabled.
It’s a Boolean with context.
If you really need to track the history of a record being enabled/disabled, I’d suggest this should be in another table. With postgres (not sure if it’s all DBs) you could create a trigger that when a record’s enabled_at field is updated, it creates a record in the log table with a from state, a to state, a timestamp, even a role/user.
That way, you could then extract the history of that record if required.
Tbh, if using postgres, you could just make a logging table that stores a JSON of the entire old record, and a JSON of the entire new record.
Would let you rewind the history of a record, see who did what, etc.
Saves having an enabled and an enabled_at where there are potentially multiple sources of truth, or faffing around with arrays, multiple fields, over-pulling data
