对数据库项使用源代码控制吗?

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

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

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

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

当前回答

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

其他回答

仅供参考，几天前Dana也提出了这个问题…源代码控制中的存储过程/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团队的自动化需求。

我总是检查我的数据库结构转储到源代码控制。全数据库转储，但我通常只是压缩和存储。

我通过保存创建/更新脚本和生成sampledata的脚本来完成。

我们使用复制和集群来管理数据库以及备份。我们使用Serena来管理SQL脚本和配置实现。在进行配置更改之前，我们将执行备份，作为更改管理流程的一部分。此备份满足我们的回滚需求。

我认为这完全取决于规模。您是在谈论需要离线备份和灾难恢复的企业应用程序吗?一个运行会计应用程序的小工作组?还是两者之间的任何地方?

推荐文章