How to design a database that supports a feature that would allow the application user to create a snapshot of their data at a point in time, a bit like version control.
It would give the user the ability to go back and see what their data looked like in the past.
Assume that the data being ‘snapshotted’ is complex and includes joins of multiple tables.
I’m looking for a way to give each application user the ability to snapshot their data and go back to it. Whole database snapshots is not what I’m looking for.
EDIT: Thanks for your answers. The 6NF answer is compelling as is the suggestion to de-normalise the snapshot data due to its simplicity.
Clarification: this is not a data warehousing question, nor is it a question about DB backup and restore; its about how to build a schema that allows us to capture the state of a specific set of related data at a point in time. The snapshots are generated by the application users when they see fit. Users do not snapshot the entire DB, just the data object they are interested in.
We did this once by creating separate database tables that contained the data we wanted to snapshot, but denormalized, i.e. every record contained all data required to make sense, not references to id’s that may or may no longer exist. It also added a date to each row.
Then we produced triggers for specific inserts or updates that did a join on all affected tables, and inserted it into the snapshot tables.
This way it would be trivial to write something that restored the users’ data to a point in time.
If you have a table:
user:
department:
your snapshot of the user table could look like this:
and a query something like
This ensures each row in the snapshot is true for that moment in time, even if department or department head has changed in the meantime.