【发布时间】：2012-02-11 11:22:03
【问题描述】：
与完全基于脚本或数据库增量工具相比，使用转储文件作为数据和架构迁移的基础有哪些优缺点？
上下文是应用程序处于生产状态，并且只有一个生产数据库。应用程序和数据库模式正在积极开发中。关键用户数据存在于生产数据库中，必须随着新版本或修复的部署而前滚。
正在讨论的解决方案是：
转储文件基础-
- 从参考点转储文件开始。
- 数据库更改脚本已签入源代码管理。
- 部署需要加载转储文件，然后运行更改脚本
架构+迁移
- 整个架构和某些非用户配置数据在 SCM 中存储为 DDL 和 DML。
- 针对最新版本架构的迁移脚本存储在 SCM 中。
- 部署需要加载架构然后迁移数据。 3.
我的直觉是使用二进制格式作为基础是不好的，但我需要能够说服其他人（如果确实如此），他们认为这是必要的。
为了更容易回答，我重新提出了这个问题。
以下是原问题：
我正在与一个团队合作开发数据库驱动的企业应用程序 并希望改进我们的流程。目前，有很多 围绕在所有层上更新数据库的手动过程。目标是 具有用于一致地更新数据库的自动化过程 一种自动化的方式，（符合原子提交和 更接近持续交付），这将带来许多 优点。
我认为架构（以及应用程序所需的某些数据） 配置）应在源代码管理中表示，并在 此外，转换和加载用户数据所需的任何脚本 当前的生产数据库。我读过这是不可取的 在源代码管理中有一个转储文件（.dmp），直观地说，我同意 强烈。但是，我不同意该项目的每个人。 相反的论点是，实际上这是不可能的，或者在 至少太难了，不从转储文件开始。我起来了 反对我的数据库知识的限制，不能真正辩论 有意义...我更多的是开发人员而不是数据库专家。 建议的替代方法是保留更改脚本以更改 转储到最新的架构。
谁能帮助我了解每种方法的优缺点 好一点？基于转储的方法是必要的，一个好主意，还是 不是一个好主意，为什么？
可能相关的一点背景：应用程序在 生产，因此每个新版本都必须导入数据作为 部署过程，以及集成和 UAT 的明显原因 这应该是真实数据。然而，这个应用程序没有“发货”，并且 由客户安装，只有一个生产实例 给定时间，内部维护。我知道会有细节 特定于我的项目，因此答案必须针对一般情况 案例。
【问题讨论】：
-
当您发布升级时，您的一个关键问题将是“您必须从多少个不同的版本进行升级”。如果所有现有系统（始终）处于相同的修订级别，则有一组选项；如果您在不同级别有不同的生产系统，那么您需要处理更复杂的问题。
-
在我们的例子中，在给定时间只有一个生产系统，因此生产数据库实例包含必须迁移到新实例或突变为新架构的最新数据。
-
奢华……无疑让生活更轻松。您可能还希望拥有一个测试系统 - 与开发系统分开 - 以便您可以在开发机器（您已经完成 N 次迁移）和生产机器（由于迁移失败，您可能不想离线）。而且，如果您进行扩展，您最终会得到多个系统。但就目前而言，您可以享受相对（强调相对）简单的过程。
-
是的实现自动化的真正重要好处之一是，除了测试代码之外，您还可以测试部署，同时减少生产和 UAT 之间的差异和其他测试实例。但问题是如何处理数据迁移以及每次都从转储开始是否不好以及为什么。
-
我的问题的一个问题是，实际上它涉及多个问题。
标签： sql database version-control continuous-integration continuous-deployment