数据库版本部署。实体框架迁移与SSDT DacPacs

Question

我有一个带有SQL Server的以数据为中心的应用程序。它将被部署的环境不在我们的控制之下，并且没有DBA（它们都是小型企业）所以我们需要尽可能自动地分发每个应用程序/数据库更新的过程。 / p>

除了应用程序版本之间的正常变化（有时候是不可预测的），我们已经知道我们需要为每个版本分发一些新的种子数据。有时，此种子数据将与我们系统中的其他数据相关。例如：在v2-v3更新过程中，我们可能需要插入2行新数据，在v5-v6更新过程中需要插入其他5行。

EF

我们已经检查了Entity Framework Db迁移（可用于自4.3.1版本以来没有Code-First的现有数据库），它以更自动和受控的方式表示传统的顺序脚本（如Fluent迁移）。

SSDT

另一方面，我们采用不同的理念，检查了SSDT及其dacpac，快照以及部署前和部署后的脚本。

问题是：

1. 这些技术/理念中哪一种更适合所描述的情况？

2. 可以使用的任何其他技术/理念？

3. 还有其他建议吗？

提前致谢。

Answer 1

这是一个有趣的问题。在Red Gate，我们希望在今年晚些时候解决这个问题，因为我们有许多客户询问我们如何提供一个简单的部署包。我们确实有SQL Packager，它基本上将SQL脚本包装到exe。

中

我想说dacpacs旨在涵盖您描述的用例。但是，据我所知，他们的工作是在应用于目标时动态生成部署脚本。缺点是在部署预先测试的SQL脚本时，您不会有温暖的模糊感。

之前我没有尝试使用dacpacs更新数据，所以我有兴趣知道它的工作原理。据我所知，它会截断目标表并重新填充它们。

我没有使用EF迁移的经验，所以我很想阅读有关此主题的任何答案。

Answer 2

我们可能会采用混合解决方案。我们不想放弃想法部署打包器，但另一方面，由于我们的应用程序的性质（小企业作为最终用户，没有DBA，没有义务升级所以多个“活着的”数据库版本共存），我们无法放弃对迁移过程的完全控制，包括架构和数据。在我们的例子中，部署前和部署脚本可能不足以（或者至少不够舒服）进行像EF迁移这样的完全迁移。添加/删除种子数据，将“一对多”更改为“多对多”关系或甚至激进的数据库架构更改（以及因此从以前发布的架构中迁移到此架构的数据）等更改可能是我们的一部分当我们的第一个版本发布时，日记工作。

所以我们可能会使用EF迁移，每个版本都有“Up”和“Down”系统。原则上，每个“Up”将使用最后一个数据库快照（以及每个Down，它的前一个）调用dacpac，每个快照都有自己的特定迁移部署参数。 EF迁移将处理版本控制线，也可能是数据迁移的一些复杂部分。

我们觉得这种混合方式更加安全。我们错过了实体框架迁移中的自动​​化和架构更改检测，因为我们错过了Dacpacs方式的版本控制线。