我已经阅读了所有 SO 问题、Coding Horror 文章，并在 Google 上搜索了修订控制数据的最佳方法。它们都可以工作，并且它们都有基于用例等的适当实现。我真正想知道的是为什么没有编写数据库来原生支持数据级别的修订？
令我感到困惑的是，API 实际上已经在交易中到位。我们开始一个事务，更改一些数据，然后提交。我们也在对数据库进行身份验证，因此存在指责。我的公司存储了我们整个数据库的月末版本，用于会计目的，相当于标签。这不是尖叫RCS吗？
分支是数据库也可以从模式而不是数据方面受益匪浅的东西。由于我真的只关心数据，这会大大增加实施的难度，我将坚持只使用标签和提交。
现在我知道数据库是非常时间关键的应用程序，因此任何不必要的开销都会被遗忘，并且一些数据库是史诗级的巨大，并且修订只会使这个大小成倍增加。每个表的选择性修订控制无疑在中小型环境中占有一席之地，其中有几毫秒的空闲时间并且数据历史具有一定程度的重要性。我想要提交，我想要日志，我想要回复，我想要差异，我想要责备，我想要标签，我想要结帐。我想要 MF-ing 版本控制。
我在某个地方有个问题...
您可以阅读有关时态数据库的信息。
在Date、Darwen 和 Lorentzos 的“时间数据与关系模型”中，作者引入了第六范式来解决跟踪时间数据的问题。
Richard Snodgrass 提出TSQL2作为 SQL 的扩展来处理时间数据。
实现包括：
一种原生解决方案是 Oracle 的闪回数据库（又名 Total Recall）。这是企业版的额外收费，但它非常酷。只要我们想保留它，它就会透明地存储数据的版本，并提供语法来查询旧版本的数据。它可以逐个表启用。
本质上，闪回数据库就像使用触发器将记录存储在跟踪表中，但对正常工作来说是光滑的、高性能的和不可见的。
一些 DBMS 实现了引擎级别的版本控制机制。不幸的是，没有独立于供应商的标准，因此它们都是专有的。Oracle 闪回已经被提及。Microsoft 在 SQL Server 中的变更数据捕获功能是另一项功能。
你忘了我要表演。DBMS 是一种相当低级的数据存储机制，在具有数十亿行的系统中，性能可能很重要。因此，如果您想要这种审计系统，您可以使用您可用的工具（例如触发器）自己构建它。
就像在文件系统中一样，并非所有文件都适合版本控制，在数据库中也并非所有行都适合版本控制。