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

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

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

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


当前回答

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

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

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

其他回答

我有一切必要的重新创建我的数据库从裸露的金属,减去数据本身。我相信有很多方法可以做到这一点,但我所有的脚本等都存储在subversion中,我们可以通过将所有这些从subversion中取出并运行安装程序来重建DB结构等。

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

我们对数据库周围的一切进行版本和源代码控制:

DDL(创建和更改) DML(参考数据、代码等) 数据模型更改(使用ERwin或ER/Studio) 数据库配置更改(权限、安全对象、常规配置更改)

我们使用Change Manager和一些自定义脚本来完成所有这些自动化作业。我们有变更管理器监视这些变更,并在变更完成时通知变更。

Sadly, I've seen more than one team developing PL/SQL programs (stored procedures in Oracle) - sometimes ten thousands LOC - just by editing the code in TOAD (a database tool), without even saving the source to files (except for deployment). Even if the database is backuped regulary (wouldn't take that for granted, though), the only way to retrieve an old version of a stored procedure is to restore the whole database, which is many GB large. And of course sometimes concurrent changes in one file lead to loss of work, when more than one developer works on the same project.

是的,总是这样。您应该能够在需要时使用一组有用的示例数据重新创建生产数据库结构。如果你不这样做,随着时间的推移,保持运行的小改变会被遗忘,然后有一天你会被咬,严重的。这是一种保险,你可能认为你不需要,但当你这样做的那一天,它的价格是它的10倍!