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

Question

我有一个带有 SQL Server 的以数据为中心的应用程序。部署它的环境不受我们控制，也没有 DBA（他们都是小型企业），因此我们需要尽可能自动化地分发每个应用程序/数据库更新。

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

EF

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

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 方式中的版本控制线控制一样。