php – 版本化Mysql数据(不只是架构)

发布时间：2020-12-13 13:11:53 所属栏目：PHP教程来源：网络整理

导读：我的办公室一直在讨论创建一个版本控制 mysql数据(而不是模式/迁移)的软件包. 基本上这个过程会像这样工作.请记住,客户端仍然像往常一样使用后端,然后像wordpress后端一样使用它.客户端将登录选择一个“分支”给它一个名称让我们说“新用户”这将克隆一个全

我的办公室一直在讨论创建一个版本控制 mysql数据(而不是模式/迁移)的软件包.

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

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

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

此外,如果客户端在开发/演示站点上工作,他们希望将其工作放在他们的工作中.

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

数据库(尤其是数据)很少存储在版本控制系统中,因为它不适合大型数据库.

在你的情况下,如果你没有太多的数据,那可能会有效,特别是因为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.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!