> Part of the reason it hasn’t taken off is because of the additional complexity it imposes on programmers.
My take is that it's specifically the additional complexity it imposes on _database_ programmers - the impacts across storage design, foreign keys and schema evolution when all data is bitemporal are profound. SQL:2011 introduced "temporal tables" but the design was arguably incomplete and implementing it ubiquitously requires a real re-think of database internals, so we're now over a decade on and these capabilities are still far from commonplace.
> However, I think part of the reason it hasn’t become more popular, given the benefits it brings, is just the name.
No disagreement from me there!
Disclosure: I work on xtdb.com, building a new database engine where bitemporality is the default. I also spoke with Kent about this last week :)
> Part of the reason it hasn’t taken off is because of the additional complexity it imposes on programmers.
My take is that it's specifically the additional complexity it imposes on _database_ programmers - the impacts across storage design, foreign keys and schema evolution when all data is bitemporal are profound. SQL:2011 introduced "temporal tables" but the design was arguably incomplete and implementing it ubiquitously requires a real re-think of database internals, so we're now over a decade on and these capabilities are still far from commonplace.
> However, I think part of the reason it hasn’t become more popular, given the benefits it brings, is just the name.
No disagreement from me there!
Disclosure: I work on xtdb.com, building a new database engine where bitemporality is the default. I also spoke with Kent about this last week :)