2 ms·

Shout out to Crux (https://opencrux.com/ https://opencrux.com/), a bitemporal database. I've been using it for a year now and it's fantastic.

chadcmulligan 6y ago
Why would you need a special database to implement this feature? Usually its just modelled by having 2 date fields and querying as appropriate.
- jandrewrogers 6y ago
  You can implement bitemporality on top of a database kernel not explicitly designed to support it but you sacrifice significant performance and scalability. It is a bit like trying to implement a graph database on top of a relational database -- it definitely works, just not well. Database kernels designed for first-class bitemporality support have low-level internal structures to optimize operations on bitemporal data models not found in typical database kernels. These features are not free if they aren't being used, hence why they are relatively rare in databases that are not explicitly bitemporal.
- refset 6y ago
  Crux timestamps sit outside of the data model and apply universally across the whole database (the data model is documents not tables), so you don't have to consciously think about managing bitemporality at all by default, but whenever you might need it, it's there. This means you don't have to adapt your queries to account for extra fields/columns, instead you just specify the timestamps of interest as simple parameters to the query datasource. Also, Crux maintains a point-in-time (a.k.a timeslice) temporal index which is really a Z-Order Curve[0] that stores the two dimensions for fast lookups in a local KV store like RocksDB or LMDB. By contrast, a userland RDBMS implementation of bitemporality will be significantly slower to execute similar point-in-time "as-of" queries. [0] https://en.m.wikipedia.org/wiki/Z-order_curve https://en.m.wikipedia.org/wiki/Z-order_curve (I work on Crux)

chadcmulligan 6y ago

Why would you need a special database to implement this feature? Usually its just modelled by having 2 date fields and querying as appropriate.

jandrewrogers 6y ago
You can implement bitemporality on top of a database kernel not explicitly designed to support it but you sacrifice significant performance and scalability. It is a bit like trying to implement a graph database on top of a relational database -- it definitely works, just not well. Database kernels designed for first-class bitemporality support have low-level internal structures to optimize operations on bitemporal data models not found in typical database kernels. These features are not free if they aren't being used, hence why they are relatively rare in databases that are not explicitly bitemporal.
refset 6y ago
Crux timestamps sit outside of the data model and apply universally across the whole database (the data model is documents not tables), so you don't have to consciously think about managing bitemporality at all by default, but whenever you might need it, it's there. This means you don't have to adapt your queries to account for extra fields/columns, instead you just specify the timestamps of interest as simple parameters to the query datasource. Also, Crux maintains a point-in-time (a.k.a timeslice) temporal index which is really a Z-Order Curve[0] that stores the two dimensions for fast lookups in a local KV store like RocksDB or LMDB. By contrast, a userland RDBMS implementation of bitemporality will be significantly slower to execute similar point-in-time "as-of" queries. [0] https://en.m.wikipedia.org/wiki/Z-order_curve https://en.m.wikipedia.org/wiki/Z-order_curve (I work on Crux)