BrainBlog for JUXT by Jason Bloomberg
In the first three installments of this series of articles, my colleague Eric Newcomer and I made the case for bitemporal databases.
In the first installment, Eric introduced the central challenge of data compliance: how traditional relational databases struggle to keep track of how values change over time.
I followed up with an explanation of how the everyday UPDATE and DELETE operations so familiar to database professionals are inherently flawed, as they erase any information about the previous state of the data they overwrite.
In the third article, Eric explored the bitemporality challenge in depth, differentiating between ‘current’ databases that track values in the present vs. bitemporal databases that can track various values at points in the past as well as when those values changed.
This article, in turn, wraps up the series. Sure, bitemporality is a nice-to-have feature, but when is it a must-have capability? How do you decide whether there is a place for a database like XTDB in your organization?
