如果用户在数据库中有几百条记录,并且想要制作一个草稿,他们可以在其中获取所有当前数据并进行一些更改并将其保存为草稿,可能会永久保存两份副本,我该怎么办?
我应该复制同一张表中的所有数据并将其标记为草稿吗?
还是只复制更改?如果不存在更改,然后使用“非草稿”数据?
用户应该能够进行更改,然后仍然回到现场并在那里进行更改,而不影响草稿?
如果用户在数据库中有几百条记录,并且想要制作一个草稿,他们可以在其中获取所有当前数据并进行一些更改并将其保存为草稿,可能会永久保存两份副本,我该怎么办?
我应该复制同一张表中的所有数据并将其标记为草稿吗?
还是只复制更改?如果不存在更改,然后使用“非草稿”数据?
用户应该能够进行更改,然后仍然回到现场并在那里进行更改,而不影响草稿?
只需在会受到影响的表中引入一个版本字段即可。
内容管理系统 (CMS) 已经这样做了。例如,您可以创建一篇博客文章,它具有版本 1。然后进行更改并获得版本 2 和更高版本。
您显然最终会存储更多的数据。不过,一个不错的好处是您可以轻松编写查询来加载数据的版本(或快照)。
作为惯例,您始终可以将最高版本号设为“活动”版本。
您可以使用 BEGIN TRANS、COMMIT 和 ROLLBACK 语句,也可以创建一个存储过程/一段代码,这意味着用户所做的任何修改都将放入临时表中,直到它们准备好投入生产。
如果您要进行大量更改,最好使用临时表,因为使用 COMMIT 等可能会导致实时数据锁定以供其他用途。
如果上述内容对您没有任何意义,这篇文章可能会有所帮助:http ://www.sqlteam.com/article/temporary-tables
编辑 - 您可以“即时”创建新表(即不是临时的,而是完整的 sql 表)并将它们命名为有意义的名称。例如,用户姓名缩写,后跟原始表名,后跟时间戳。
然后,您可以长时间以编程方式创建、修改和删除这些表,并与实时表进行比较。您需要跟踪正在创建的表的数量,以防您的数据库增长到庞大的规模。
唯一令人头疼的问题是将更改放回实时数据中。例如,如果有人将一段数据放入一个新表中,然后在 3 周后决定在进行更改后将其发送到现场。在这种情况下,实时数据可能无论如何都已更改,并可能取代用户将提交的更改。
不过,您可以通过一些创造性的编码来解决这个问题。有很多方法可以解决这个问题,所以如果你在下一步卡住了,你可能想开始一个新问题。希望这至少能给你一些启发。