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

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

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

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


当前回答

查看使用源代码控制管理数据库更改的LiquiBase。

其他回答

是的。代码就是代码。我的经验法则是,我需要能够从头构建和部署应用程序,而不需要查看开发或生产机器。

我已经使用RedGate SQL Compare Pro与脚本文件夹进行模式同步,然后我将所有更新提交给版本控制。效果很好。

是的,我认为版本化你的数据库是很重要的。当然不是数据,而是模式。

在Ruby On Rails中,这是由框架通过“迁移”来处理的。任何时候修改db,都需要编写一个脚本来应用更改并将其检入源代码控制。

我的团队非常喜欢这个想法,所以我们使用shell脚本和Ant将该功能添加到基于java的构建中。我们将该过程集成到部署例程中。在其他不支持DB版本开箱即用的框架中编写脚本来完成同样的事情是相当容易的。

如果你的数据库是SQL Server,我们可能有你正在寻找的解决方案。SQL源代码控制1.0现在已经发布了。

http://www.red-gate.com/products/SQL_Source_Control/index.htm

它集成到SSMS中,并提供数据库对象和VCS之间的粘合剂。“脚本输出”是透明的(它在底层使用SQL比较引擎),这应该使它使用起来如此简单,以至于开发人员不会被阻止采用该过程。

一个可供选择的Visual Studio解决方案是ReadyRoll,它被实现为SSDT数据库项目的子类型。这采用了一种迁移驱动的方法,更适合DevOps团队的自动化需求。

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