Storing booleans as timestamps sounds crazy, but in reality it is actually not a bad idea. In this video I talk about the pros/cons of this approach so you can evaluate if it is right for you.


📚 Materials/References:

The Tweet: https://x.com/VicVijayakumar/status/1842583502878834747


🌎 Find Me Here:

My Blog: https://blog.webdevsimplified.com
My Courses: https://courses.webdevsimplified.com
Patreon: https://www.patreon.com/WebDevSimplified
Twitter: https://twitter.com/DevSimplified
Discord: https://discord.gg/7StTjnR
GitHub: https://github.com/WebDevSimplified
CodePen: https://codepen.io/WebDevSimplified


⏱️ Timestamps:

00:00 - Introduction
00:22 - Main Benefit
01:22 - Main Drawback
02:08 - Implementation/Drawback


#Database #WDS #CleanCode

Web Dev Simplified

Storing booleans as timestamps in databases offers benefits for debugging and analytics, such as knowing when certain actions occurred. However, it increases storage requirements significantly. This method is beneficial for enterprise applications but may not be necessary for smaller projects.

Why You Should Replace Your Booleans With Timestamps

That’s really handy. By storing timestamps, we not only determine if this value is falsy or not but also when it was created, which can be very useful.

Good idea, but only really works on smaller data sets due to the number of bytes needed to store date compared to boolean (as stated in the video). From an enterprise view data is expensive to store, but useful so only store what you need.
This fails if you use tri state boolean (nullable boolean) where you need to record a user accepting, rejecting something and the default is null.
A better solution to this would be an additional audit table which records the row, date/time and change. This would only store What’s necessary, and is extensible for not just boolean but any data types.