是否存在版本控制数据库存储引擎？
我只是想知道是否存在允许您对行级别内容进行版本控制的存储引擎类型。例如，如果我有一个包含 ID、名称、值的简单表，ID 是 PK，我可以看到第 354 行以 (354, "zak", "test")v1 开头，然后更新为 (354, "zak", "this is version 2 of the value")v2 ，并且可以看到行上的更改历史记录，其中包含类似选择历史记录（值）的内容，其中 ID = 354。
这是一种深奥的事情，但它比拥有每次进行更改时继续编写这些单独的历史表和函数......
I was just wondering if a storage engine type existed that allowed you to do version control on row level contents. For instance, if I have a simple table with ID, name, value, and ID is the PK, I could see that row 354 started as (354, "zak", "test")v1 then was updated to be (354, "zak", "this is version 2 of the value")v2 , and could see a change history on the row with something like select history (value) where ID = 354.
It's kind of an esoteric thing, but it would beat having to keep writing these separate history tables and functions every time a change is made...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
看来您正在寻找更多审核功能。 Oracle 和其他一些 DBMS 具有完整的审计功能。但许多 DBA 最终仍然实施基于触发器的行审计。这一切都取决于您的需求。
Oracle 支持多种审计粒度，可以通过命令行轻松配置。
我看到您被标记为 MySQL，但询问了任何存储引擎。不管怎样，其他答案也说了同样的事情，所以我要删除这篇文章，因为它最初是关于闪回功能的。
It seems you are looking more for auditing features. Oracle and several other DBMS have full auditing features. But many DBAs still end up implementing trigger based row auditing. It all depends on your needs.
Oracle supports several granularities of auditing that are easy to configure from the command line.
I see you tagged as MySQL, but asked about any storage engine. Anyway, other answers are saying the same thing, so I'm going delete this post as originally it was about the flashback features.
显然，您确实需要 MySQL 解决方案，因此这可能不会对您有太大帮助，但 Oracle 有一个称为 Total Recall（更正式的闪回存档）的功能，它可以自动执行您当前手动执行的过程。存档是一组压缩表，这些表会自动填充更改，并且可以使用简单的
AS OF语法进行查询。当然，作为 Oracle，他们会为此收费：唉，除了企业版之外，它还需要额外的许可证。 了解更多信息 (PDF)。
Obviously you are really after a MySQL solution, so this probably won't help you much, but Oracle has a feature called Total Recall (more formally Flashback Archive) which automates the process you are currently hand-rolling. The Archive is a set of compressed tables which are populated with changes automatically, and queryable with a simple
AS OFsyntax.Naturally being Oracle they charge for it: it needs an additional license on top of the Enterprise Edition, alas. Find out more (PDF).
Oracle 和 Sql Server 都将此功能称为“更改数据捕获”。目前还没有 MySql 的等效项。
Oracle and Sql Server both call this feature
Change Data Capture. There is no equivalent for MySql at this time.您可以使用触发器实现类似的行为（搜索“捕获所有数据库更改的触发器”） - 特别是如果它们实现 SQL92
INFORMATION_SCHEMA。否则我会同意 mrjoltcola
编辑：我提到的 MySQL 和触发器的唯一问题是（从我下载的最新社区版本开始）它要求用户帐户具有
SUPER权限，这会让事情变得有点难看You can achieve similar behavior with triggers (search for "triggers to catch all database changes") - particularly if they implement SQL92
INFORMATION_SCHEMA.Otherwise I'd agree with mrjoltcola
Edit: The only gotcha I'd mention with MySQL and triggers is that (as of the latest community version I downloaded) it requires the user account have the
SUPERprivilege, which can make things a little uglyCouchDB 对每项更改都有完整的版本控制，但它是 NOSQL 世界的一部分，因此与您当前正在做的事情相比，这可能是一个相当疯狂的转变。
CouchDB has full versioning for every change made, but it is part of the NOSQL world, so would probably be a pretty crazy shift from what you are currently doing.
关于 google bigtable 的维基百科文章提到它允许通过向表添加时间维度来进行版本控制：
还有一些 bigtable 类型 dbms 的非 google 实现的链接。
The wikipedia article on google's bigtable mentions that it allows versioning by adding a time dimension to the tables:
There are also links there to several non-google implementations of a bigtable-type dbms.
我认为 Google DB 引擎 Big table 做了类似的事情：它将时间戳与行的每次更新相关联。
也许你可以尝试一下 Google App Engine。
有一篇 Google 论文解释了Big Table 的工作原理。
I think Big table, the Google DB engine, does something like that : it associate a timestamp with every update of a row.
Maybe you can try Google App Engine.
There is a Google paper explaining how Big Table works.
《重构数据库》一书对这个问题有一些见解。
但它也指出，除了仔细地进行更改并手动管理之外，目前没有真正的解决方案。
The book Refactoring Databases has some insights on the matter.
But it also points out there is no real solution currently, other then carefully making changes and managing them manually.
一种近似的方法是时态数据库 - 它允许您查看整个数据库在过去不同时间的状态。但我不确定这是否完全回答了你的问题；它不允许您在时间 t1 查看第 1 行的内容，同时又允许您在单独的时间 t2 查看第 2 行的内容。
One approximation to this is a temporal database - which allows you to see the status of the whole database at different times in the past. I'm not sure that wholly answers your question though; it would not allow you to see the contents of Row 1 at time t1 while simultaneously letting you look at the contents of Row 2 at a separate time t2.
“这是一件深奥的事情，但每次进行更改时都必须继续编写这些单独的历史表和函数......”
我不会称之为审计跟踪（这显然就是你所说的）一个“深奥的东西”......
而且：数据库更新的历史和现实的历史之间仍然存在差异。历史数据库表确实应该用于反映现实的历史，而不是数据库更新的历史。
数据库更新的历史记录已由 DBMS 保存在其日志和日志中。如果有人需要查询数据库更新的历史记录，那么他/她应该真正求助于日志和日志，而不是任何类型的应用程序级构造，它们永远不能提供足够的保证来反映< em>所有更新。
"It's kind of an esoteric thing, but it would beat having to keep writing these separate history tables and functions every time a change is made..."
I wouldn't call audit trails (which is obviously what you're talking of) an "esoteric thing" ...
And : there is still a difference between the history of database updates, and the history of reality. Historical database tables should really be used to reflect the history of reality, NOT the history of database updates.
The history of database updates is already kept by the DBMS in its logs and journals. If someone needs to inquire the history of database upates, then he/she should really resort to the logs and journals, not to any kind of application-level construct that can NEVER provide sufficient guarantee that it reflects ALL updates.