我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。

令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。

不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。

在这方面有什么最佳实践吗?你有哪些行之有效的策略?


当前回答

我使用SQL CREATE脚本从MySQL workbench导出,然后使用他们的“导出SQL ALTER”功能,我最终得到了一系列创建脚本(当然编号)和ALTER脚本,可以应用它们之间的更改。

3.- Export SQL ALTER script Normally you would have to write the ALTER TABLE statements by hand now, reflecting your changes you made to the model. But you can be smart and let Workbench do the hard work for you. Simply select File -> Export -> Forward Engineer SQL ALTER Script… from the main menu. This will prompt you to specify the SQL CREATE file the current model should be compared to. Select the SQL CREATE script from step 1. The tool will then generate the ALTER TABLE script for you and you can execute this script against your database to bring it up to date. You can do this using the MySQL Query Browser or the mysql client.Voila! Your model and database have now been synchronized!

来源:MySQL Workbench Community Edition: Schema同步指南

当然,所有这些脚本都在版本控制下。

其他回答

我所见过的最佳实践是创建一个构建脚本,在登台服务器上废弃并重新构建数据库。每次迭代都有一个用于数据库更改的文件夹,所有更改都用“Drop…创建“”。这样,您可以通过将构建指向您想要版本的文件夹,随时回滚到较早的版本。

我相信这是用NaNt/CruiseControl完成的。

我通过编写脚本输出所有对象(表定义、索引、存储过程等)来源控制数据库模式。但是,至于数据本身,只需依赖定期备份。这确保了所有的结构更改都被正确的修订历史记录捕获,但不会在每次数据更改时给数据库带来负担。

我们坚持使用变更脚本和主数据定义脚本。这些代码与任何其他源代码一起签入CVS。PL/SQL(我们是Oracle商店)在CVS中也是源代码控制的。变更脚本是可重复的,并且可以传递给团队中的每个人。基本上,仅仅因为它是一个数据库,就没有理由不对它进行编码并使用源代码控制系统来跟踪更改。

虽然这个问题有很多很好的答案,但大多数答案都不包括市场上的创新变化,特别是商业工具。

下面是一个简短的数据库版本控制工具列表,我列出了每个工具的优缺点(完全披露:我为DBmaestro工作)

红门——已经上市很多年了。它使用集成了基于文件的版本控制的脚本来提供数据库对象的版本控制。

DBVS——使用集成了基于文件的版本控制的脚本来提供数据库对象的版本控制。

DBmaestro——在真实的数据库对象上提供版本控制过程(签出/签入)的强制执行。因此,版本控制存储库是否与应用程序使用的数据库同步是没有问题的。

我鼓励您阅读资深数据库专家Ben Taylor在LinkedIn https://www.linkedin.com/pulse/article/20140907002729-287832-solve-database-change-mangement-with-dbmaestro上发布的关于数据库强制变更管理解决方案的全面、公正的评论

哇,这么多答案。对于可靠的数据库版本控制,您需要对更改数据库的代码进行版本控制。一些CMS提供配置管理工具,比如Drupal 8中的配置管理工具。以下是一个实用步骤的概述,可以安排您的工作流并确保数据库配置是版本化的,即使是在团队环境中: