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

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

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

EF

我们已经检查了实体框架Db Migrations（自4.3.1发布以来不存在Code-First的现有数据库可用），它以更自动和受控的方式（如Fluent Migrations）代表传统的顺序脚本。

SSDT

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

问题是：

这些技术/哲学中的哪一种更适合描述的情况？

任何其他可以使用的技术/哲学？

任何其他建议？

提前致谢。

---

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

我想说dacpacs旨在涵盖您描述的用例。 不过，据我了解，他们的工作是在应用到目标时动态生成部署脚本。 缺点是，当您部署预测试的SQL脚本时，您不会产生温暖的模糊感。

我之前没有尝试使用dacpacs更新数据，所以我很想知道它的工作情况。 据我记得，它截断目标表并重新填充它们。

我没有EF迁移的经验，所以我会好奇地阅读关于这个主题的任何答案。

---

我们可能会采用混合解决方案。 我们不想放弃想法部署包装器，但另一方面，由于我们的应用程序的性质（小企业作为最终用户，没有DBA，没有义务升级如此多的“活着”数据库版本共存），我们不能放弃对迁移过程的完全控制，包括模式和数据。 在我们的例子中，部署前和部署后脚本可能不够（至少不够舒适），无法像EF Migrations这样完全迁移。 像添加/删除种子数据，将“一对多”更改为“多对多”关系，甚至是根本性的数据库模式更改（以及因此，从任何先前发布的模式向该模式的数据迁移）的变化可能都是我们的一部分我们的第一个版本发布时的日记工作。

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

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

链接地址: http://www.djcxy.com/p/10685.html

上一篇: Database versions deployment. Entity Framework Migrations vs SSDT DacPacs

下一篇: How do I connect an AudioFilePlayer AudioUnit to a 3DMixer?