是否存在版本控制数据库存储引擎？答案

【问题标题】：Does a version control database storage engine exist?是否存在版本控制数据库存储引擎？
【发布时间】：2011-01-31 00:05:09
【问题描述】：

我只是想知道是否存在允许您对行级内容进行版本控制的存储引擎类型。例如，如果我有一个简单的表，其中包含 ID、名称、值，并且 ID 是 PK，我可以看到第 354 行以 (354, "zak", "test")v1 开始，然后更新为 (354, "zak", "this is version 2 of the value")v2 ，并且可以在行上看到更改历史记录，例如选择历史记录（值），其中 ID = 354。

这是一种深奥的东西，但每次进行更改时都必须继续编写这些单独的历史表和函数...

【问题讨论】：

+1 有趣的问题。我想知道除了Oracle的Total Recall还有没有其他解决方案。

标签： sql mysql database refactoring-databases

【解决方案1】：

您似乎在寻找更多的审计功能。 Oracle 和其他几个 DBMS 具有完整的审计功能。但许多 DBA 最终仍会实施基于触发器的行审计。这完全取决于您的需求。

Oracle 支持多种审计粒度，这些粒度很容易从命令行配置。

我看到您被标记为 MySQL，但询问了任何存储引擎。无论如何，其他答案都在说同样的事情，所以我要删除这篇文章，因为它最初是关于闪回功能的。

【讨论】：

闪回查询和闪回表不是永久数据存储；它们只是启用从 UNDO 表空间中恢复数据。我说“只是”，显然这些是强大的功能，但它们并不是真正的“数据版本控制”解决方案。
是的。如果您阅读了我的编辑，我在您发表评论之前添加了该内容。
我可能应该完全编辑它，因为这可能会产生误导。快速扫描一个问题给我带来了麻烦。 :)

【解决方案2】：

您可以使用触发器实现类似的行为（搜索“捕获所有数据库更改的触发器”） - 特别是如果它们实现 SQL92 INFORMATION_SCHEMA。

否则我会同意 mrjoltcola

编辑：我要提到的关于 MySQL 和触发器的唯一问题是（截至我下载的最新社区版本）它要求用户帐户具有 SUPER 权限，这会使事情变得有点难看

【讨论】：

是的，我阅读了关于“版本控制”的问题的第一部分并想到了闪回，但后来意识到他似乎正在寻找长期审计。我已经编辑了我的答案。谢谢。
同意 - 我第一次读的方式和你一样，但后来发现想要审计更常见

【解决方案3】：

很明显，您确实在追求 MySQL 解决方案，所以这可能对您没有多大帮助，但 Oracle 有一个称为 Total Recall（更正式的闪回存档）的功能，它可以自动执行您当前手动处理的过程。存档是一组压缩表，这些表会自动填充更改，并且可以使用简单的AS OF 语法进行查询。

自然是 Oracle，他们为此收费：唉，它需要在企业版之上的额外许可。 Find out more (PDF).

【讨论】：

【解决方案4】：

对此的一种近似是临时数据库 - 它允许您查看整个数据库在过去不同时间的状态。不过，我不确定这是否完全回答了您的问题；它不允许您在时间 t1 查看第 1 行的内容，同时让您在单独的时间 t2 查看第 2 行的内容。

【讨论】：

【解决方案5】：

Oracle 和 Sql Server 都将此功能称为 Change Data Capture。目前还没有 MySql 的等价物。

【讨论】：

【解决方案6】：

我认为 Google 数据库引擎 Big table 做了类似的事情：它将时间戳与行的每次更新相关联。

也许你可以试试 Google App Engine。

有一篇谷歌论文解释了how Big Table works。

【讨论】：

【解决方案7】：

CouchDB 对所做的每项更改都有完整的版本控制，但它是 NOSQL 世界的一部分，因此与您目前所做的相比，这可能是一个非常疯狂的转变。

【讨论】：

【解决方案8】：

google 的 bigtable 上的 wikipedia article 提到它允许通过向表格添加时间维度来进行版本控制：

每个表格都有多个维度（其中一个是时间字段，允许版本控制）。

那里还有几个非谷歌实现的 bigtable-type dbms 的链接。

【讨论】：

【解决方案9】：

Refactoring Databases这本书对这个问题有一些见解。

但它也指出目前没有真正的解决方案，除了仔细进行更改并手动管理它们。

【讨论】：

【解决方案10】：

“这是一种深奥的东西，但是每次进行更改时都必须继续编写这些单独的历史表和函数......”

我不会将审计跟踪（这显然是您所说的）称为“深奥的东西”......

而且：数据库更新的历史和现实的历史还是有区别的。历史数据库表应该真正用于反映现实的历史，而不是数据库更新的历史。

数据库更新的历史记录已由 DBMS 保存在其日志和日志中。如果有人需要查询数据库更新的历史记录，那么他/她真的应该求助于日志和日志，而不是任何可以永远提供充分保证它反映所有更新。

【讨论】：