News for hackers. Stuff that matters.
Re:The Value of Bitemporality – Whose Time Is It Anyway? by paulcarey on Sunday April 21, 2019 @04:08PM (#19714253)
You could consider ‘partitioning’ your DB when you migrate your schema so each DB instance only deals with a single bitemporal slice eg after 5 migrations you have 5 distinct database instances. This approach avoids bloat assuming the vast majority of queries would be served by the most recent instance, while not precluding serving verbatim responses from earlier instances.
Re:The Value of Bitemporality – Whose Time Is It Anyway? by lichtenberger on Sunday April 21, 2019 @04:25PM (#19714352)
I wonder why so few people seem to think about persistent data structures (persistent in the functional sense, that is immutability -- copy-on-write). Basically we implemented a form of hash array based tries for https://sirix.io ... or it's just like how ZFS stores objects adding levels of indirect blocks/pages on demand with bitsets storing which indexes are really set to avoid having arrays with a lot of null references. For sure you have to copy the path to the root, just like snapshots work in ZFS or Btrfs, but I think that data is neglegable when you basically also do versioning on a per record-level/per revision level. At least thus we can restore each revision in the same time, you do not have to have a "history table", which is inefficient to query in contrast to the most recent revision table.
Re:The Value of Bitemporality – Whose Time Is It Anyway? by lichtenberger on Sunday April 21, 2019 @04:27PM (#19714368)
But it's schema-less ;-)