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

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

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

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


当前回答

是的,我们的源代码控制我们的sql脚本也与subversion。这是一个很好的实践,您可以在需要时使用默认数据重新创建模式。

其他回答

我通常为我所做的每一个更改构建一个SQL脚本,另一个用于恢复这些更改,并将这些脚本置于版本控制之下。

这样我们就可以根据需要创建一个新的最新数据库,并且可以轻松地在不同版本之间切换。每次我们发布版本时,我们都会把脚本放在一起(需要一些手工工作,但实际上很少困难),所以我们也有一组可以在版本之间转换的脚本。

是的,在你说之前,这与Rails和其他东西非常相似,但它似乎工作得很好,所以我毫不犹豫地承认我无耻地提出了这个想法:)

我相信每个DB都应该在源代码控制下,开发人员应该有一种简单的方法从头创建他们的本地数据库。受Visual Studio for Database Professionals的启发,我创建了一个开源工具,脚本MS SQL数据库,并提供了一种简单的方法将它们部署到您的本地DB引擎。试试http://dbsourcetools.codeplex.com/。玩得开心, -内森。

我非常喜欢Rails ActiveRecord迁移。它将DML抽象为ruby脚本,然后可以在源存储库中轻松地进行版本化。

然而,通过一些工作,您可以做到同样的事情。任何DDL更改(ALTER TABLE等)都可以存储在文本文件中。为文件名保留编号系统(或日期戳),并按顺序应用它们。

Rails在DB中还有一个'version'表,用于跟踪上一次应用的迁移。你可以很容易地做到这一点。

我已经在http://dbdeploy.com/上使用了ThoughtWorks的dbdeploy工具。它鼓励使用迁移脚本。在每个版本中,我们将更改脚本合并到一个文件中,以简化理解,并允许dba“支持”更改。

我们对所有dabase创建的对象进行源代码控制。为了让开发人员保持诚实(因为你可以在没有源代码控制的情况下创建对象),我们的dba定期寻找不在源代码控制中的任何东西,如果他们找到了什么,他们就会丢弃它,而不询问它是否ok。