在可见之前，需要批准的数据库记录存储更改的最佳方法是什么？

Question

我需要将用户输入的更改存储到特定表中，但在管理用户查看和批准之前不会显示这些更改。虽然这些更改仍处于暂挂状态，但我仍会显示旧版本的数据。存储这些变更等待批准的最佳方法是什么？

我想过几种方法，但无法弄清楚什么是最好的方法。这是一个非常小的网络应用程序。一种方法是使PendingChanges表模仿其他表的模式，然后一旦更改得到批准，我就可以用信息更新真实表。另一种方法是进行某种记录版本控制，其中我在表中存储多个版本的数据，然后始终使用已标记为已批准的最高版本号来提取记录。这将限制额外表的数量（我需要为多个表执行此操作），但是每次我提取一组记录时都需要我做额外的处理以确保我得到正确的表。

这些方法或其他可能有用的个人经历？

更新：只是为了澄清，在这种特殊情况下，我对历史数据不感兴趣。我只需要某种方式来批准用户在网站上发布之前所做的任何更改。因此，用户将编辑他们的“配置文件”，然后管理员将查看该修改并批准它。一旦获得批准，它将成为显示的值，并且不需要保留旧版本。

有人尝试过以下解决方案，您可以在任何需要在特殊PendingChanges表中将其作为XML跟踪的表中存储挂起的更改吗？每个记录都有一个列，表示更改所针对的表，可能存储将要更改的记录的id的列（如果是新记录则为null），更改时存储的日期时间列，以及用于存储已更改记录的xml的列（可以序列化我的数据对象）。由于我不需要历史记录，在批准更改后，将更新真实表格并删除PendingChange记录。

有关该方法的任何想法？

Answer 1

绝对将它们存储在主表中，并带有一列以指示数据是否被批准。

批准更改后，无需复制。过滤未经批准的数据的额外工作是数据库在您考虑它时应该做的事情。如果您对批准的列进行索引，那么做正确的事情不应该太繁琐。

Answer 2

大小是你的敌人。如果你正在处理大量的数据和大量的行，那么将历史与当前混合在一起将会打击你。如果你加入其他数据并确保你有正确的行，你也会遇到问题。

如果您需要保存历史数据以显示随时间的变化，我会选择单独的历史数据表，一旦获得批准，即可更新实时数据。它只是全能的清洁剂。

如果您有很多具有此机制但不需要保留历史记录的数据类型，我建议使用一个常见的队列来检查待处理的项目，比如存储为xml。这将允许管理员只读取一个表，并使您能够非常轻松地将此功能添加到系统中的任何表。

Answer 3

我在银行业领域工作，我们有这种需求 - 一个用户所做的更改必须在被另一个用户批准后才能反映出来。我们使用的设计如下

1. 主要表A
2. 另一个表B存储更改的记录（因此与第一个完全相似）+ 2个附加列（FKey到C和代码表示更改类型）
3. 第三个表C，存储所有需要批准的记录
4. 存储历史的第四个表D（您可能不需要这个）。

我推荐这种方法。它非常优雅地处理所有场景，包括更新和删除。

Answer 4

鉴于大多数公开交易公司面临的SOx合规运动，我在这方面有相当多的经验。通常我一直在使用一个单独的表，其中带有时间戳的挂起更改，带有某种标志列。负责管理此数据的人员会获得待处理更改的列表，并可以选择接受或不接受。当一块数据被接受时，我使用触发器将新数据集成到表中。虽然有些人不喜欢触发器方法，但宁愿将其编码到存储过程中。这对我来说效果很好，即使在相当大的数据库中也是如此。复杂性可能有点难以处理，特别是在处理一个更改与另一个更改直接冲突的情况以及处理这些更改的顺序时。持有请求数据的表永远无法删除，因为它持有“面包屑”可以说，如果需要追溯特定情况下发生的事情，则需要这样做。但在任何方法中，都需要评估风险，例如我提到的冲突数据，并且需要有一个业务逻辑层来确定这些情况下的流程。

我个人不喜欢相同的表方法，因为在数据存储不断被更改的情况下，表中的这些额外数据可能会不必要地使表上的请求陷入困境，并且需要更多细节如何索引表和执行计划。

Answer 5

我会创建一个带有标志的表，并创建一个像

这样的视图

 CREATE OR REPLACE VIEW AS 

  SELECT * FROM my_table where approved = 1

它可以帮助分离aprovement和查询之间的依赖关系。但如果需要对视图进行更新，可能不是最好的主意。

移动记录可能需要考虑一些性能。但分区表可以做一些非常相似的事情。

Answer 6

由于这是一个Web应用程序，我将假设读取次数多于写入次数，并且您希望某些内容合理快速，并且您的冲突解决方案（即无序批准）会导致相同的行为 - 最新更新是使用的那个。

你提出的两种策略都是相似的，它们每个变更集都有一行，必须处理冲突等，唯一的区别是是否将数据存储在一个或两个表中。鉴于这种情况，出于性能原因，两个表似乎是更好的解决方案。如果您的数据库支持，您还可以使用一个表和最近批准的更改视图来解决此问题。

Answer 7

另一个想法是有三张桌子。

• 一个是保存原始数据的主表。
• 第二个会保留建议的数据。
• 第三个会保存历史数据。

这种方法使您能够快速轻松地回滚，并在需要时为您提供审计跟踪。

Answer 8

我认为第二种方法是更好的方法，因为它可以更好地扩展到多个表。此外，额外处理将是最小的，因为您可以根据“已批准”位创建表的索引，并且您可以将查询专门化为拉取批准（查看）或未批准（批准）条目。