正在处理需要输入更改权限的数据输入Web应用程序。后端数据库是PostgreSQL 9.6。不需要保留更改历史记录（审核记录），只需要保留记录的原始副本和授权的完整副本即可。检查其他问题，建议的解决方案似乎有些过头。
并且使用link之类的时态数据库解决方案，肯定显得过分了。
一个选项是每个字段都有两列，一列保存干净副本，另一列保存脏副本，以及一个记录状态枚举字段。数据提供者的任何插入或修改将被写入脏字段，并且状态将适当更改。当管理员授权更改时，脏字段值将被复制到清除字段，并且状态将更改。数据的公共视图只会选择干净的字段并过滤出插入的记录。
这似乎有点骇人听闻，并且不遵循规范化规则。但这似乎是满足要求的最简单的解决方案。使用单独的表保存更改时，处理父子关系（在父记录插入之前授权子记录插入）没有问题。
如果有人可以提出更好的设计，我将不胜感激。
因此，需要澄清一些要求。该应用程序要求授权用户可以输入有关其项目的详细信息。任何更改或添加都必须由管理员进行审核，然后才能生效。如前所述，目前无需保留更改历史记录。一个项目几乎总是由一个人编辑。
使用PostgreSQL 9.6，Flask和SQLAlchemy作为ORM和HTML 5，并使用jquery作为前端。
希望使解决方案尽可能简单，尤其是使Web界面保持简单。
答案 0 :(得分：1)
在您的Web应用程序中，具有适当权限的人将更改字段。
更改应转到一个单独的表，该表引用了应更改的列和状态列（如果更改被授权或拒绝）。
该表应该为时间戳添加1行，因为有1个以上的用户可能会尝试更改同一字段，当然还有一列用于进行更改的用户ID /名称。
审阅者应该能够看到网络上的更改并批准。
批准将意味着更改该工作表中的状态列。
单独的脚本可以获取该工作表中的更改并更新主表。
要指出的一件事：
无需保留更改历史记录（审核记录），
根据我的经验，一旦您开始批准更改，此类要求就会很快出现/更改。您应该考虑到这一点
答案 1 :(得分：0)
在不了解您的全部要求的情况下，很难说出“过度杀伤”的含义。
“两列”方法似乎可能需要大量代码，并且容易出现错误-更多代码意味着更多错误。在某些情况下，它还需要前端逻辑来隐藏某些列，而在其他情况下，则不需要。
我更喜欢“单个表，每个更改一行，状态标志”的解决方案。更少的代码（更新单个列并插入，而不是更新许多列），并且如果将来需求发生变化，则更易于扩展。处理前端需求更容易-显示“已接受并草稿”或“仅接受”状态。