4 ms·
My takeaway is (for applications that need this): #1: Keep rows immutable. Don't use UPDATE or DELETE. #2: Store the time columns you need, e.g. insertion or
by ToBeBannedSoon 7y ago
My takeaway is (for applications that need this):
#1: Keep rows immutable. Don't use UPDATE or DELETE.
#2: Store the time columns you need, e.g. insertion or transaction time, and/or event generation time, etc.
- lichtenberger 7y agoHm, and why storing so much information redundantly? Why not providing a tailored index structure... basically snapshotting page-trees efficiently :-)
- ToBeBannedSoon 7y agoIf the db internally supports efficient temporal tracking, then yes by all means. If it doesn't, then I don't see a way for the developer around the redundancy.