3 ms·
interesting. last:: -- I assume, means 'most-recent'. maintaining pre-calculated 'most recent' is very useful (as long as I can ask 'what was most recent, sa
by platform 8y ago
interesting.
last:: -- I assume, means 'most-recent'.
maintaining pre-calculated 'most recent' is very useful (as long as I can ask 'what was most recent, say, yesterday at 1pm').
Most of the 'hand-made' append-only data schema design suffer from not being able to return 'joined' most-recent datums, quickly.
Because a 'usual' implementation requires doing
join with select max on business or system (or both) time stamp
My understanding that both DBs I mentioned previously do copy of write for temporal data, but I am not sure if they do any document level-diffs.
- lichtenberger 8y agoYes, the revisions can be reconstructed in merely the same time, for instance it doesn't matter if you open the most recent revision or any past revision regarding system/transaction time. We also do not have to store the transaction time more than once (in the revision - root page). And if you do a fine granular modification, we usually do not copy and rewrite the whole page with currently 512 records (it depends on the versioning algorithm you use).
- lichtenberger 8y agoI think they might store a bitemporal that is two dimensional index. However, I think this is not really efficient to reconstruct a specific revision in comparison to our approach, where we just have to follow pointers from the revision root pages.