前端之家收集整理的这篇文章主要介绍了
php – 版本化Mysql数据(不只是架构)，
前端之家小编觉得挺不错的，现在分享给大家，也给大家做个参考。
我的办公室一直在讨论创建一个版本控制
mysql数据(而不是模式/迁移)的软件包.
基本上这个过程会像这样工作.请记住,客户端仍然像往常一样使用后端,然后像wordpress后端一样使用它.客户端将登录选择一个“分支”给它一个名称让我们说“新用户”这将克隆一个全新的数据库,允许用户在那里工作“分支”而不影响实时.一旦客户端完成数据更改,他们就会将数据分支合并到“master”(实时)中.
在合并时,它会将实时和“新用户”分支数据导出到sql文件并执行svn diff并合并更改.
引发这种想法的情况是,如果我们的客户需要对网站进行一系列更改,但不想将这些数据置于实际状态,而他们进行更改时,他们也不想影响其他同事网站的更改.基本上复制了开发人员在Git等存储库中工作时所做的事情.
此外,如果客户端在开发/演示站点上工作,他们希望将其工作放在他们的工作中.
我想打开讨论,以了解这是否是一个好主意？
我们可能会遇到什么问题？
在处理数据时这是一个很好的编程实践吗？
这样的事情已经存在吗？
@H_
404_15@
数据库(尤其是数据)很少存储在版本控制系统中,因为它不适合大型
数据库.
在你的情况下,如果你没有太多的数据,那可能会有效,特别是因为mysqldump can produce a delimited text format(有可能与之前的版本不同)
我仍然会建议使用单独的git repo和专用工具来管理架构和数据更改.例如,LiquidBase可以为您的数据库提供“源代码管理”.
您还可以使用专用数据库：off-scale.
如果您是手动执行此操作,那么您在“Recipes for Continuous Database Integration”中总结了一些好的做法.
截至mentioned here,即使是架构：
I learned the hard way that applying database schema changes cannot be reliably done without a comprehensive step-by-step plan and,similarly,the order of relationship dependencies are important.
Just storing the “current” or “end” schema is not sufficient. There are many changes that cannot be retroactively applied A->C without knowing A->B->C and some changes B might involve migration logic or corrections.
