版本控制 Mysql 数据（不仅仅是模式）

Question

我的办公室一直在谈论创建一个可以版本控制 mysql 数据（而不是模式/迁移）的包。

基本上这个过程会像这样工作。请记住，客户端仍然像往常一样使用后端，然后像 wordpress 后端一样使用图像。客户端将登录选择一个“分支”给它一个名称让我们说“新用户”这将克隆一个全新的数据库，允许用户在“分支”上工作而不影响实时。一旦客户端完成数据更改，他们会将那里的数据分支合并到“主”（实时）中。

在合并时，它会将实时和“新用户”分支数据导出到 sql 文件并执行 svn diff 并合并更改。

引发这个想法的情况是，如果我们的客户需要对那里的站点进行大量更改，但又不想将这些数据投入使用，并且当他们进行更改时，他们也不想影响其他同事的站点更改.基本上复制了开发人员在 Git 等存储库中工作时所做的工作。

此外，如果客户在开发/演示网站上工作，他们希望将他们所做的工作投入使用。

我想开始讨论以了解这是否是一个好主意？ 我们可能会遇到什么问题？ 在处理数据时，这是一种好的编程习惯吗？ 类似的东西已经存在了吗？

Answer 1

数据库（尤其是它们的数据）很少存储在版本控制系统中，因为它不能很好地适应大型数据库。

在您的情况下，如果您没有太多的数据，这可能会起作用，尤其是因为 mysqldump can produce a delimited text format（它有机会与以前的版本进行比较）

我仍然建议使用单独的 git 存储库和专用工具来管理架构和数据更改。例如，LiquidBase 可以为您的数据库提供“源代码控制”。
您还拥有一个专门的数据库：off-scale。

如果您要手动执行此操作，那么“Recipes for Continuous Database Integration”中总结了一些好的做法。

作为mentioned here，即使是架构：

我了解到，如果没有全面的分步计划，就无法可靠地应用数据库架构更改，同样，关系依赖关系的顺序也很重要。
仅存储“当前”或“结束”模式是不够的。在不知道A->B->C 的情况下，有许多更改无法追溯应用A->C，而B 的某些更改可能涉及迁移逻辑或更正。

Answer 2

您的要求是否简单如下：

• 后端代码相同；
• 实时使用主数据；
• 最终用户（或组）处理孤立的数据；
• 无迁移，最终用户只能修改数据（DML），不允许修改架构（DDL）；

如果这些是要求，那么您可以使用多个数据库。考虑 MySQL 服务器中的以下数据库：

• 主数据库
• branch_demo
• branch_brian
• branch_sandbox
• ...

这些数据库共享完全相同的架构，只有数据不同。在每个分支中，我们都有一个特殊的表（即 dbinfo），用于跟踪父分支（可能是 masterdb）、创建日期时间和其他详细信息，如访问级别等。

• 身份证
• 分行名称
• parent_branch
• created_on
• lastmod_on

您可以允许最终用户在单独的分支上工作，只需允许他们在 UI 中选择特定数据库，其中 masterdb 被选择为默认数据库，并在 LIVE 中使用。

• 创建一个新分支，就像克隆一个数据库一样简单；
• 将较新的分支合并到 master，可以使用 MySQL 中的 REPLACE 语句来处理；

如果您想跟踪数据的变化，您可以创建一个特殊的表来记录活动。