Question

I don’t do database work that often so this is totally unfamiliar territory for me.

I have a table with a bunch of records that users can update. However, I now want to keep a history of their changes just in case they want to rollback. Rollback in this case is not the db rollback but more like revert changes two weeks later when they realized that they made a mistake. The distinction being that I can’t have a transaction do the job.

Is the current practice to use a separate table, or just a flag in the current table?

It’s a small database, 5 tables each with < 6 columns, < 1000 rows total.

Answer 1

Frustrated’s answer is one solution – another is an audit table that records the changes, when, and by whom. It’s really a question of approach. If performance on your application tables is critical, and they could grow massively using an ‘active row’ approach, then the audit table is better, as it would separate the history from the active stuff (and I would hope that fixing user errors is less common than ‘normal’ transactions).