与完全基于脚本或数据库增量工具相比，使用转储文件作为数据和模式迁移的基础有哪些优缺点？
上下文是应用程序处于生产状态，并且只有一个生产数据库。应用程序和数据库模式正在积极开发中。关键用户数据存在于生产数据库中，并且必须随着新版本或修复的部署而前滚。
正在讨论的解决方案是：
转储文件基础 -
- 从参考点转储文件开始。
- 数据库更改脚本被检入源代码控制。
- 部署需要加载转储文件，然后运行更改脚本
架构 + 迁移
- 整个模式和某些非用户配置数据在 SCM 中存储为 DDL 和 DML。
- 针对最新版本架构的迁移脚本存储在 SCM 中。
- 部署需要加载模式然后迁移数据。3.
我的直觉是使用二进制格式作为基础是不好的，但我需要能够说服其他人（如果确实如此），他们认为这是必要的。
我重新制定了这个问题，以便更容易回答。
以下是原始问题：
我正在与一个团队合作开发数据库驱动的企业应用程序，并希望改进我们的流程。目前，围绕更新所有层的数据库有很多手动过程。目标是拥有以自动化方式一致地更新数据库的自动化流程（符合原子提交的理念，更接近于持续交付），这将带来许多优势。
我认为模式（以及应用程序配置所需的某些数据）应该在源代码控制中表示，此外，从当前生产数据库转换和加载用户数据所需的任何脚本。我已经读过，不建议在源代码管理中使用转储文件 (.dmp)，直观地说，我非常同意。但是，我不同意该项目的每个人。相反的论点是，实际上不可能，或者至少太难，不从转储文件开始。我遇到了数据库知识的极限，无法真正进行有意义的辩论……我更多的是开发人员，而不是数据库专家。建议的替代方法是保留将转储更改为最新模式的更改脚本。
有人可以帮助我更好地了解每种方法的优缺点吗？基于转储的方法是必要的、好主意还是不是好主意，为什么？
可能相关的一些背景知识：应用程序正在生产中，因此每个新版本都必须在部署过程中导入数据，并且由于集成和 UAT 层的明显原因，这应该是真实数据。但是，此应用程序不是由客户“交付”和安装的，在给定时间只有一个生产实例，由内部维护。我意识到会有特定于我的项目的细节，所以答案必须针对一般情况。