3 ms·
These are good reasons to use a bitemporal database [1]. A log gives you "transaction time" but you need to create an efficient representation of "valid time"
by refset 7y ago
These are good reasons to use a bitemporal database [1].
A log gives you "transaction time" but you need to create an efficient representation of "valid time" for backfilling and corrections.
[1] https://en.wikipedia.org/wiki/Temporal_database https://en.wikipedia.org/wiki/Temporal_database
Disclosure: I work on a database for Kafka that provides point-in-time bitemporal Datalog queries https://github.com/juxt/crux https://github.com/juxt/crux
- elvinyung 7y agoYeah, I'm currently getting bitten by various workloads that query by `created_at` instead of a canonical timestamp :) Thanks, I'll take a look! For the "valid time" primitive I was thinking of implementing something like a hybrid logical clock that CockroachDB has (but with looser guarantees, mostly just need uniqueness and monotonicity). A sequential ID would provide a slightly nicer interface for pagination but has all the problems that I previously mentioned.