与完全基于脚本或数据库增量工具相比，使用转储文件作为数据和模式迁移的基础有哪些优缺点？
上下文是应用程序正在 生产环境 中，并且只有一个 生产环境 数据库 . 应用程序和数据库架构正在积极开发中 . 关键用户数据存在于 生产环境 数据库中，必须通过部署新版本或修订来推进 .
正在讨论的解决方案是：
转储文件基础 -
-
从参考点转储文件开始 .
-
数据库alter scripts被检入源代码管理 .
-
部署需要加载转储文件，然后运行alter脚本
架构迁移
-
整个模式和某些非用户配置数据在SCM中存储为DDL和DML .
-
针对最新版本模式的迁移脚本存储在SCM中 .
-
部署需要加载架构然后迁移数据 . 3 .
我的直觉是使用二进制格式作为基础是不好的，但我需要能够说服其他人（如果确实如此），谁认为这是必要的 .
我重新制定了这个问题，以便更容易回答 .
以下是原始问题：
我正在与数据库驱动的企业应用程序团队合作，并希望改进我们的流程 . 目前，围绕所有层更新数据库有很多手动过程 . 目标是实现自动化流程，以自动化方式更新数据库（符合原子提交的理念，更接近持续交付），这将带来许多优势 . 我认为应该在源代码控制中表示模式（以及应用程序配置所需的某些数据），此外，还需要从当前 生产环境 数据库转换和加载用户数据所需的任何脚本 . 我已经读过，不建议在源代码管理中使用转储文件（.dmp），直觉上，我强烈同意 . 但是我对项目的每个人都不同意 . 反驳的论点是，实际上不可能，或者至少太难，不能从转储文件开始 . 我违背了我对数据库知识的限制，无法真正进行有意义的辩论......我更像是一名开发人员，而不是数据库专家 . 建议的替代方案是保留更改脚本以将转储更改为最新模式 . 有人能帮我理解每种方法的优缺点吗？基于转储的方法是必要的，一个好主意，还是一个好主意，为什么？可能相关的一点背景：应用程序正在 生产环境 中，因此每个新版本必须作为部署过程的一部分导入数据，并且出于集成和UAT层的明显原因，这应该是真实数据 . 然而，这个应用程序不是由客户“运送”和安装的，在给定时间内只有一个 生产环境 实例，在内部维护 . 我意识到我的项目会有详细的细节，所以答案必须解决一般情况 .
2 回答
使用不同的脚本进行全新安装和升级会产生很多不好的事情 . 我在2000年代早期为Oracle电子商务套件工作，根据我的经验，adpatch工具消除了这种致命的变化 .
在Oracle收购了我的雇主之后，我绝对厌恶的一个关键技术是坚持所有脚本都可以完全重新运行而不会出现错误 - 并且可以完全运行且没有任何错误 . 一旦我们的贴片质量达到鼻烟，我就意识到这完全是天才 .
我学到的另一个关键技术是拥有强大的数据库比较/验证脚本 .
如果您的架构状况良好，您的数据集将最容易照顾自己 .
我一直在使用的大多数项目都有明确的SQL脚本，用于模式创建和初始数据插入 . （并使用alter语句和数据迁移升级脚本）
还有像Liquibase这样的东西用于管理数据库更改 .
http://www.liquibase.org/bestpractices