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

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

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

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


当前回答

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

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

其他回答

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

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

RedGate很棒,当数据库发生变化时,我们会生成新的快照(一个小的二进制文件),并将该文件作为资源保存在项目中。每当我们需要更新数据库时,我们使用RedGate的工具包来更新数据库,并且能够从空数据库创建新的数据库。

RedGate也制作数据快照,虽然我个人没有使用过,但它们同样强大。

是的……我们的数据库是在ERwin中设计的,每个版本的ddl是自动生成的。ERwin文件保存在我们的源代码控制系统中(实际上,我们的工程文档也是如此)。

任何数据库接口代码都应该进入版本控制(存储过程、函数等)。

对于结构和数据,这是一个判断。我个人对我的数据库保持一个干净的结构模板,但由于它们的大小,不将它们存储在版本控制中。但是将它存储在版本控制中是非常有益的,即使对于只有历史记录也是如此。

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