Design Record update approval

Question

Problem statement:
To always approve record updates before the changes reflect in main record. Want to try solving this problem using SQL database.
Eg. User: { "name" : "Ravi Kumar", "city" : "Bangalore" } Say we want to update the city to "Delhi" but it has to undergo approval before it reflects in the main record.

Once approved. It should show: User: { "name" : "Ravi Kumar", "city" : "Delhi" }

Required Features:

1. Changes must get approved before they reflect in the main record
2. audit trail of the record to be maintained
3. how to support table joins? what if record is fetched using joining multiple tables? Basically if db is normalised.

Possible Solutions:

1. Have a additional column "approved" in the table. All approved records will have status 1 and rest will be 0. To get the current record we have to get record with the most recent timestamp with approved=1.

2. Have 2 tables one which contains the main table and another for approvals. When someone approves then we make changes to the record in main table.

Questions:

1. How to incorporate joins when there is normalisation? Is it simple or complex when joins are must? Is it even possible?
2. In case of joins, can we still implement using ORMs like hibernate?
3. If there are multiple updates waiting for approval on the same record and each update modifies different set of fields. If all of the records are approved then the record in consideration might only have the last update changes(Assuming one of above solutions are used).
   
   Eg. There is a record in the main table and no unapproved records for it. Now a user changes a property say "name" and submits for approval. Another user changes property "city" and submits for approval. Another user changes property "salary" and submits for approval. All unapproved records are approved. Now last update(which changed salary property), that change contains old name not the one which is in first update. How to get all the approved changes.
   This can be achieved by storing only changed properties instead of the whole. But it comes with cost of more code changes.

How are these problems tackled in the industry?

Related questions:
What's the best way to store changes to database records that require approval before being visible?
Structure to handle changes to records that require approval

Answer 1

If you want to be very careful about approving changes and you expect so many changes that it is likely that more changes will be made to a record before prior changes can be approved, then your best approach would be to have a separate set of tables with one record for each proposed change.

These "pending change" records could (should) include extra information about the change transaction, such as who proposed it and when.

Your process for handling all of these changes, and especially conflicting or overlapping changes will depend on your business rules, which you haven't stated definitively. Options include:

• Prevent a second change while one is pending
• Last change approved wins
• Changes must be approved in sequence, overlaying earlier pending changes on top of the official data so that there is a presumption that all earlier changes will be approved prior to applying later changes

Regarding normalized databases and joins, this presents no special problems in your case. You will join the tables containing official, approved data as you would in any case. If you want to join to an interim/pre-approved version of a record, you should create a view which reflects these changes overlapped over the official data and then join to that view.