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.
[ Parent
| on HN ]
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 ;-)