3 ms·
I agree this is more of an application level concern than a database thing. If you need to maintain a history for the user requirement then you will naturally
by benjaminwootton 3y ago
I agree this is more of an application level concern than a database thing. If you need to maintain a history for the user requirement then you will naturally land on a scheme like this.
We also have help from other quarters nowadays.
Databases often provide a time travel feature where we can query AS OF a certain date.
Some people went down the whole event sourcing / CQRS / Kafka route where there is an immutable audit log of updates.
Data warehousing has moved on such that we can implement “slowly changing data” there.
All in all, complicating our application logic, migrations and GDPR in order to maintain history in line of business applications might not be worthwhile.
- refset 3y ago> Databases often provide a time travel feature where we can query AS OF a certain date. This is a good overview of SQL:2011 temporal functionality support across the major players: https://illuminatedcomputing.com/posts/2019/08/sql2011-survey/ https://illuminatedcomputing.com/posts/2019/08/sql2011-surve...
- code_biologist 3y agoI'm curious if the author of that blog ever completed their work with temporal Postgres. I know about [1] but unfortunately work on hosted Postgres most often where the extension isn't an option. [1] https://pgxn.org/dist/temporal_tables/ https://pgxn.org/dist/temporal_tables/