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

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

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

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


当前回答

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

其他回答

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

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

我们在源代码控制下有创建/修改脚本。至于数据库本身,当您有数百个表并且每分钟处理大量数据时,对所有数据库进行版本化将是CPU和HDD的杀手。这就是为什么在我看来,备份仍然是控制数据的最佳方式。

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

RedGate软件提供了一些很棒的工具,可以帮助你对数据库进行版本化。确保让开发者为开发工作构建自己的独立本地数据库,而不是依赖于“开发服务器”,因为“开发服务器”有时可能停机,有时也可能不停机。

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