为关系数据库构建分支版本控制模型

Question

我是数据库设计师，在我当前的项目中，我正在实现在 RDBMS 中同时编辑数据行所需的版本控制功能。项目要求说，数据编辑会话可以持续几个小时或几天，直到执行提交。此外，在不同用户同时修改相同数据时产生的冲突应该以手动和半自动解决的可能性进行处理。换句话说，所需的编辑工作流类似于面向文档的版本控制系统（例如 SVN 或 Git）中使用的工作流。因此，传统的 OLTP 方法和冲突解决策略（MVCC、乐观/悲观锁）不能满足我的约束。我对现有工具进行了一些观察，这些工具为分支版本历史记录和多版本工作流提供了可能性：

• ArcSDE - ESRI 的 ArcGIS 支持通过 ArcSDE数据层对地理数据库进行版本控制；
• Oracle Workspace Manager - Oracle 数据库的特性，提供高度的版本隔离和数据历史管理；
• SQL:2011 时间特性，包括有效时间和事务时间支持。

SQL:2011 没有解决我的问题，因为它提供了对“线性”编辑历史的支持，而不是我正在寻找的分支。ESRI 和 Oracle 的解决方案是不错的候选者，但我很失望它们都具有用于操作版本的供应商特定接口。目前似乎没有人可以为关系数据的分支版本控制提供行业标准的解决方案（就像 SQL:2011 为时态表和线性版本历史所做的那样）。作为一名新来的数据库研究员，我想了解：

• 关系数据库社区是否对开发分支数据版本控制的标准模型感兴趣？在该领域的任何贡献或研究是否有价值？（例如，以语言改进的形式对 SQL2011 中的时间特征进行标准化）
• 开发人员和数据库设计人员是否缺乏独立于数据库的开源中间件（类似于 ArcSDE），它支持关系数据的分支版本管理，还是在 RDBMS 本身中引入此类功能会更好？

我想我可以尝试深入挖掘并提出一些标准模型或子语言来处理类似 Git 的版本控制，但我不知道从哪里开始。

Answer 1

使用带有跟踪每个更改的触发器的审计表可以非常轻松地管理和跟踪数据修改（插入、更新、删除）。

在管理 DDL（结构更改或过程代码更改）或 DCL（对象授权）时，需要进行版本控制。

市场上有一些数据库强制变更管理的解决方案，它们为您提供对数据库对象的版本控制。

如果我将 RDBMS 与文件系统进行比较，那么它将是存储在共享驱动器中的一个目录，所有开发人员都可以同时修改该目录。数据库分支与Git/SVN中的分支过程相同——创建一个新目录，相当于创建一个新的模式/数据库。此外，还存在需要涵盖的共享情况，并需要制定强制更改策略以防止代码被覆盖。

更多信息欢迎阅读《数据库版本控制权威指南》白皮书