我已经阅读了所有SO问题，编码恐怖文章，并搜索了我的大脑，寻找修改控制数据的最佳方法。他们都工作，他们都有基于用例等的适当实现。我真正想知道的是为什么没有编写数据库来本地支持数据级别的修订？
我感到困惑的是，API已经在交易中实际存在。我们启动交易，更改一些数据，然后提交。我们也在对数据库进行身份验证，因此存在责任。我公司存储整个数据库的月末版本，用于会计目的，等同于标签。这不是尖叫RCS吗？
分支是数据库可以从模式而不是数据中获益的东西。因为我真的只关心数据，这会大大增加实现的难度，我会坚持只使用标签和提交。
现在我知道数据库是非常时间关键的应用程序，所以任何不必要的开销都被忽略了，而且有些数据库是史诗般的巨大数据库，而且修订版只能取代这个数量。每个表，选择加入版本控制无疑在中小规模的环境中占有一席之地，其中有几毫秒的备用时间和数据历史具有一定程度的重要性。我想要提交，我想要日志，我想要恢复，我想要差异，我想要责备，我想要标签，我想要结帐。我想要MF-ing版本控制。
我在某处有一个问题......
答案 0 :(得分：3)
您可以阅读temporal databases。
在"Temporal Data & the Relational Model"日期，Darwen和Lorentzos中，作者引入sixth normal form来解释跟踪时态数据的问题。
Richard Snodgrass提出TSQL2作为SQL的扩展来处理时态数据。
实施包括：
答案 1 :(得分：3)
一个原生解决方案是Oracle的Flashback Database (aka Total Recall)。这是企业版的额外费用，但它非常酷。只要我们想要保留数据，它就会透明地存储数据版本，并提供语法来查询旧版本的数据。它可以逐个表启用。
本质上，闪回数据库就像使用触发器在跟踪表中存储记录一样，但对于正常工作而言，它是光滑，高效和不可见的。
答案 2 :(得分：1)
多个DBMS实现了引擎级版本控制机制。不幸的是，没有独立于供应商的标准，因此它们都是专有的。已经提到过Oracle闪回。 Microsoft在SQL Server中的更改数据捕获功能是另一个功能。
答案 3 :(得分：0)
你忘了我想要表现。 DBMS是一种相当低级别的数据存储机制，在具有数十亿行的系统中，性能可能很重要。因此，如果您需要这种审核系统，您可以使用可用的工具（例如触发器）自行构建。
就像在文件系统中一样，并非所有文件都适用于版本控制，在数据库中并非所有行都适合版本控制。