[Lots of discussion about this on SO, but almost all dealing in SQL, so a lot of it is N/A to my question as far as I could tell]
i'm writing a CRUD app with react
/redux
, a firebase
backend, & AWS lambda
functions where necessary.
My users will be interested in seeing what's been changed and when in their records, but I'm struggling with an efficient way to do this.
My current plan is to maintain a collection of "record updates" records with fields like previousVal
, changeDate
, and userMakingChange
. Redux
has some great middleware that would make this fairly straightforward in the client-side.
the img is the database schema i had in mind. Firebase stresses very flat data structures, and I want revision histories to load on-demand, separate from their user/record, hence the intermediate tables of revision histories
.
So, my question(s):
- How do revision history systems handle ballooning storage requirements?
- Is there a less complex way to do this? I assume there has to be an industry 'best-practice' for something like this.