在实体框架中使用模型第一种方法迁移

Question

我已经设置了一个系统，我采用了模型第一种方法，因为它对我来说更具逻辑意义。现在，即使我在模型中有一些变化，我现在所做的是 -

1. 使用实体框架的从模型生成数据库功能。我创建一个虚拟数据库并应用这些脚本。它首先删除我的所有数据和表，然后使用实体框架生成的最新sql文件更新数据库。
2. 现在我使用 Visual Studio的架构比较功能，并为我的本地数据库以及正在生产的数据库生成迁移脚本。
3. 我手动浏览脚本并验证它们。完成后，我在生产实例上运行迁移脚本。

问题：主要问题是真的很乏味，因为我是从本地系统进行的，连接到我的prod数据库非常慢，有时我的视觉工作室也会崩溃。有没有更清洁的方法来做到这一点？哪个更自动化，以至于我的笔记本电脑对生产实例上的数据库迁移不负实际责任？

Answer 1

您可以尝试Database Migration Power Pack - 它允许创建更改脚本而不是完整的数据库脚本，但在后面它执行与您手动执行的相同的过程。问题是提到tool will not work with EF5。

不幸的是EF migrations目前不支持通过EDMX创建的模型。迁移目前仅支持代码优先方法。

Answer 2

在Schema First设计中，我使用ApexSQL Diff（非常类似于RedGate的产品，可能更便宜一点） - 一个好的第三方工具比VS数据库项目更容易使用使用像RoundHousE这样的脚本应用程序工具很容易应用。

在Model First中使用它可以遵循Schema First方法，使用如帖子中描述的Model-Schema-Diff-Schema-Model循环;请考虑以下指南/注释，以简化流程。 架构差异方法不需要繁琐，缓慢或过度手动。

1. 当前版本的数据库模式是通过应用一系列数据库补丁（或DDL / DML脚本）获得的。

   工具（我们使用RoundHousE）会根据需要自动应用脚本。它记录信息以了解已应用的脚本。应用相同的脚本是幂等的。

2. 针对本地数据库进行的差异化;可以通过所有以前的更改脚本以自动方式构建此本地数据库。这个最新的本地一直是最新模型变化的差异目标。

   远程/实时数据库从未用作差异目标。稍后可以将相同的脚本应用于测试（然后是实时）数据库。由于所有操作都以相同的方式完成，因此该过程在所有数据库上都是可重复的。

   唯一的“问题”是未经深思熟虑的更新可能会导致数据在新的限制/约束下无效。当然，在推送到实时数据库之前，这很容易识别，修复和重新区分。

3. 一旦将diff提交给源控件，必须应用于分支。要“撤消”先前提交的更改脚本，需要创建应用反向操作的新差异。没有隐含的缩减版本。

   我们有一个[Hg]模型分支，它有效地充当必须统一的模式锁;这可能被视为一个弱点，但它在小团队发展方面运作良好。

4. 像Huagati DBML / EDMX这样的工具用于将Schema同步回Model，这在开发时非常有用。这个小宝石确实能够收回成本并成为周期的一部分。当使用它时，很容易“更新到模型”或在SSMS（或其他）中进行模式更改，然后将它们重新带回来。

Code First迁移是“OK”（绝对比没有好！），但我仅使用它们，因为高级差异工具不支持Azure SQL（又名SQL数据库）不暴露各种系统信息。 （差异可以按照正常情况在本地完成，但ApexSQL Diff生成的DDL / DML对于Azure SQL并不总是很友好 - 加上，我有机会学习稍微不同的方法： - ）

通过Power Pack进行Code First迁移的一些优点：可以在C＃中执行更新任务，而不是仅限于DDL / DML（可以方便），自动降级（虽然我质疑它们的使用），不需要购买第三方工具（可能很昂贵），更容易与Azure SQL集成/部署，与特定数据库供应商（理论上）相关性较小等。

虽然Code First迁移（以及自动化）与绝对可怕的 Drop-and-Recreate方法相比是一个很好的进步，但我更喜欢在开发时使用专用的SQL工具。