Its more you have a table like so: ID VALUE CHANGED 1 1 date 2 2 date+n etc... Where you never actually update id 1 in place and setu

Its more you have a table like so: ID VALUE CHANGED 1 1 date 2 2 date+n etc... Where you never actually update id 1 in place and setup views etc... to wrap over the table(s) that ignore the history. I use this all the time in postgresql, you'd be shocked how often having the history of a specific entry getting updated comes in handy. Even for application logic (like, slow down, why is this one table getting updated 1000 times a second? lets reject updates for a bit cause something has gone haywire) Highly recommend it, BUT if you implement it you need to also deal with the history accumulation. I just setup window functions to limit the history to N in size generally or setup some cleanup job to clean out really old entries at a certain point. I don't work in healthcare but like the GP I consider UPDATE in place a generally bad idea as well. You can turn on audit logging but the issue with that is the logs are always in another place so nobody ever looks at it until they need to, and only then do you find out the audit logs weren't setup right/etc.... But yes just like functional programming, don't mutate in place, append immutable values to the end. Same idea.