问题
Working on a data-entry web application, that requires changes to be authorised. The back-end database is PostgreSQL 9.6. There is no requirement for a change history (audit trail) to be kept, only a dirty copy of the record and an authorised clean copy. Checking other questions the suggested solutions seem rather overkill.
link1, link2, link3
And using a temporal database solution like link, definatly seems overkill.
One option would be to have two columns for each field, one holding the clean copy and the other dirty copy and a record status enum field. Any inserts or amendments by the data providers would be written to the dirty field and the status changed appropriately. When an admin authorises the changes, then the dirty field value is copied to the clean field and the status changed. The public view of the data would only pick up the clean fields and filter out inserted records.
This seems a bit of a hack and does not follow rules of normalisation. But it does seem to be the simplest solution that meets the requirements. It does not have the problem with dealing with parent child relations (authorising a child record insert before a parent record insert) when using a separate table to hold the changes.
If anybody could suggest a better design, I would be grateful.
Update 1
So to clarify the requirements a little. The application has the requirement that authorised users can enter details about their projects. Any changes or additions have to be reviewed by admins before they are allowed to be put live. As mentioned currently there is no need for history of changes to be kept. A project will nearly always be edited by one person.
Using PostgreSQL 9.6, Flask with SQLAlchemy for the ORM and HTML 5 and jquery for the frontend.
Would like to keep the solution as simple as possible, specifically keeping the web interface simple.
回答1:
In your web application someone with the proper rights would change a field.
The change should go to a separate table with a reference to the column that should be changed and a status column if the change is authorized or rejected.
The table should have 1 extra row for timestamp since more than 1 users may try to change the same field and of course a column for the user id/name who made the change.
The reviewer should be able to see the changes in the web and approve.
Approval would mean change of the status column in that work table.
A separate script could pick up changes in that work table and update main table.
One thing to point out:
There is no requirement for a change history (audit trail) to be kept,
From my experience once you start with approving changes such requirements can come/change very fast. You should take that into consideration
回答2:
Without understanding your full requirements, it's hard to say what "overkill" might mean.
The "two columns" approach seems like it might require a fair amount of code, and be a little bug-prone - more code means more bugs. It also requires front-end logic to hide some columns in some cases, but not others.
I much prefer the "single table, one row for each change, status flag" solution. Less code (updating a single column and inserting, rather than updating lots of columns), and easier to extend if the requirements do change in future. It's easier to handle front-end requirements - either show "accepted and draft", or "only accepted" status.
来源：https://stackoverflow.com/questions/51302006/structure-to-handle-changes-to-records-that-require-approval