版本化Mysql数据（不只是架构）

Question

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

基本上这个过程会像这样工作。请记住，客户端仍然像往常一样使用后端，然后像使用wordpress后端一样使用它。客户端将登录选择＆＃34;分支＆＃34;给它一个名字让我们说＆＃34;新用户＆＃34;这将克隆一个全新的数据库，允许用户在那里工作＆＃34;分支＆＃34;没有影响生活。一旦客户端完成数据更改，他们就会将数据分支合并到＆＃34; master＆＃34;（实时）。

在合并时，它将导出现场和新用户＆＃34;将数据分支到sql文件并执行svn diff并合并更改。

引发这种想法的情况是，如果我们的客户需要对网站进行一系列更改，但又不想将这些数据置于实际状态，并且当他们进行更改时，他们不希望影响其他同事网站更改。基本上复制了开发人员在Git等存储库中工作时所做的事情。

此外，如果客户在dev / demo网站上工作，他们希望将他们的工作放在现场。

我想开启讨论，以了解这是否是一个好主意？ 我们可能会遇到什么问题？ 在处理数据时，这是一个很好的编程实践吗？ 这样的事情是否已经存在？

Answer 1

数据库（尤其是数据）很少存储在版本控制系统中，因为它无法很好地扩展到大型数据库。

在你的情况下，如果你还没有太多多少数据，那可能会有效，特别是因为mysqldump can produce a delimited text format（它有可能与先前版本不同）

我仍然会建议使用单独的git repo和专用工具来管理架构和数据更改。例如，LiquidBase可以为您的数据库提供“源代码管理” 作为专用的专业数据库，您还拥有off-scale。

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

作为mentioned here，即使是架构：

  

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

Answer 2

您的要求是否如下：

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

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

• masterdb
• branch_demo
• branch_brian
• branch_sandbox
• ...

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

• ID
• BRANCHNAME
• parent_branch
• created_on
• lastmod_on

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

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

如果要跟踪数据中的更改，可以创建一个特殊的表来记录活动。