我的办公室一直在谈论创建一个版本控制mysql数据(而不是模式/迁移)的软件包.
基本上这个过程会像这样工作.请记住,客户端仍然像往常一样使用后端,然后像使用wordpress后端一样使用它.客户端将登录选择一个"分支"给它一个名称让我们说"新用户"这将克隆一个全新的数据库,允许用户在那里工作"分支"而不影响实时.一旦客户端完成数据更改,他们就会将数据分支合并到"主"(实时)中.
在合并时,它会将实时和"新用户"分支数据导出到sql文件并执行svn diff并合并更改.
引发这种想法的情况是,如果我们的客户需要对网站进行一系列更改,但不想将这些数据置于实际状态,并且当他们进行更改时,他们也不希望影响其他同事网站更改.基本上复制了开发人员在Git等存储库中工作时所做的事情.
此外,如果客户端在开发/演示站点上工作,他们希望将他们的工作放在现场.
我想开启讨论,以了解这是否是一个好主意？我们可能会遇到什么问题？在处理数据时,这是一个很好的编程实践吗？这样的事情已经存在吗？
数据库（尤其是它们的数据）很少存储在版本控制系统中，因为它对于大型数据库来说不能很好地扩展。
在您的情况下，如果您没有太多数据，这可能会起作用，特别是因为 amysqldump可以生成分隔文本格式（有机会与以前的版本进行比较）
我仍然会推荐一个单独的 git 存储库和一个专用工具来管理架构和数据更改。例如，LiquidBase可以提供“数据库的源代码控制”。
您还拥有一个专门的数据库：off-scale .
如果您要手动执行此操作，那么您可以在“持续数据库集成秘诀”中总结出良好的实践。
正如这里提到的，即使对于模式：
我惨痛地认识到，如果没有全面的分步计划，应用数据库模式更改就无法可靠地完成，同样，关系依赖关系的顺序也很重要。
仅存储“当前”或“结束”模式是不够的。有许多更改无法A->C在不知情的情况下追溯应用A->B->C，并且某些更改B可能涉及迁移逻辑或更正。