0

与完全基于脚本或数据库增量工具相比,使用转储文件作为数据和模式迁移的基础有哪些优缺点?

上下文是应用程序处于生产状态,并且只有一个生产数据库。应用程序和数据库模式正在积极开发中。关键用户数据存在于生产数据库中,并且必须随着新版本或修复的部署而前滚。

正在讨论的解决方案是:

转储文件基础 -

  1. 从参考点转储文件开始。
  2. 数据库更改脚本被检入源代码控制。
  3. 部署需要加载转储文件,然后运行更改脚本

架构 + 迁移

  1. 整个模式和某些非用户配置数据在 SCM 中存储为 DDL 和 DML。
  2. 针对最新版本架构的迁移脚本存储在 SCM 中。
  3. 部署需要加载模式然后迁移数据。3.

我的直觉是使用二进制格式作为基础是不好的,但我需要能够说服其他人(如果确实如此),他们认为这是必要的。


我重新制定了这个问题,以便更容易回答。

以下是原始问题:

我正在与一个团队合作开发数据库驱动的企业应用程序,并希望改进我们的流程。目前,围绕更新所有层的数据库有很多手动过程。目标是拥有以自动化方式一致地更新数据库的自动化流程(符合原子提交的理念,更接近于持续交付),这将带来许多优势。

我认为模式(以及应用程序配置所需的某些数据)应该在源代码控制中表示,此外,从当前生产数据库转换和加载用户数据所需的任何脚本。我已经读过,不建议在源代码管理中使用转储文件 (.dmp),直观地说,我非常同意。但是,我不同意该项目的每个人。相反的论点是,实际上不可能,或者至少太难,从转储文件开始。我遇到了数据库知识的极限,无法真正进行有意义的辩论……我更多的是开发人员,而不是数据库专家。建议的替代方法是保留将转储更改为最新模式的更改脚本。

有人可以帮助我更好地了解每种方法的优缺点吗?基于转储的方法是必要的、好主意还是不是好主意,为什么?

可能相关的一些背景知识:应用程序正在生产中,因此每个新版本都必须在部署过程中导入数据,并且由于集成和 UAT 层的明显原因,这应该是真实数据。但是,此应用程序不是由客户“交付”和安装的,在给定时间只有一个生产实例,由内部维护。我意识到会有特定于我的项目的细节,所以答案必须针对一般情况。

4

2 回答 2

1

我参与的大多数项目都有用于模式创建和初始数据插入的显式 SQL 脚本。(以及使用更改语句和数据迁移升级脚本)

还有像 Liquibase 这样的用于管理数据库更改的东西。

http://www.liquibase.org/bestpractices

于 2012-01-30T17:42:42.517 回答
1

新安装和升级使用不同的脚本会导致很多不好的事情。我在 2000 年代初为 Oracle E-Business Suite 工作,而根据我的经验,adpatch 工具消除了这种致命的变化。

在甲骨文收购我的雇主之后,我绝对讨厌的一项关键技术是坚持所有脚本都可以完全无错误地重新运行 - 并且完全可以无错误地运行。一旦我们的补丁质量达到鼻烟,我意识到这完全是天才。

我学到的另一个关键技术是拥有强大的数据库比较/验证脚本。

如果您的架构状况良好,您的数据集将最容易自行维护。

于 2012-02-11T03:22:03.343 回答