在实体框架中使用模型优先方法迁移
我已经建立了一个系统，我已经采用了模型的第一种方法，因为它对我来说更合乎逻辑。 现在，即使我在模型中有一些变化，我现在所做的是 -
问题 ：主要的问题是非常乏味，因为我从本地系统执行它，所以连接到我的prod数据库非常慢，有时我的视觉工作室也崩溃。 有没有更干净的方法来做到这一点？ 哪种更自动化，使我的笔记本电脑不负责生产实例上的数据库迁移？
您可以尝试使用数据库迁移电源包 - 它允许创建更改脚本而不是完整的数据库脚本，但在后面它可以执行与手动操作相同的过程。 问题是提到的工具不适用于EF5。
不幸的是，EF迁移目前不支持通过EDMX创建的模型。 迁移目前仅支持代码优先方法。
在架构优先设计中，我使用了ApexSQL Diff（很可能与RedGate的产品非常相似，可能便宜一点） - 一个好的第三方工具比VS数据库项目更容易使用，并且易于使用脚本应用工具像RoundHousE。
在模型中使用它第一种方法可以遵循模式优先方法，使用模型 - 模式 - 差异 - 模式 - 模型的循环，如文章中所述; 请考虑下面的这些指导方针/说明以简化流程。 schema-diff方法不需要繁琐，缓慢或过于手动。
数据库模式的当前版本是通过应用一系列数据库补丁（或DDL / DML脚本）获得的。
一个工具（我们使用RoundHousE）根据需要自动应用脚本。 它记录信息以了解哪些脚本已被应用。 应用相同的脚本是幂等的。
针对本地数据库执行的差异; 这个本地数据库可以从所有以前的更改脚本以自动方式构建。 最新的本地化始终是最新型号变化的差异化目标。
远程/活动数据库从不用作差异目标。 相同的脚本可以稍后应用于测试（然后生活）数据库。 由于一切都以同样的方式完成，所以这个过程在所有数据库上都是可重复的。
唯一的“问题”是没有经过深思熟虑的更新可能导致在新的限制/约束下无效的数据。 当然，在推送到实时数据库之前，这很容易识别，修复和重新比较。
一旦差异提交到源代码控制，它必须应用在分支上。 要“撤消”以前提交的更改脚本，需要创建一个应用反向操作的新差异。 没有隐含的降版本。
我们有一个[Hg]模型分支，它有情感地充当一个必须统一的模式锁; 这可能被认为是一个薄弱环节，但它在小团队发展方面运作良好。
使用像Huagati DBML / EDMX这样的工具将Schema同步回模型，这在开发时非常有用。 这个小宝石确实为自己付出，是循环的一部分。 当使用这种方法时，也可以很容易地“更新到模型”，或者在SSMS（或其他）中进行模式更改，然后将它们带回。
Code First迁移是“OK”（肯定比naught更好），但我只使用它们，因为不会暴露各种sys信息，因此高级diff工具不支持Azure SQL（又名SQL数据库）。 （差异可以按照正常情况在本地完成，但ApexSQL Diff会生成对Azure SQL并不总是友好的DDL / DML - 另外，这是我学习一种稍微不同的方法的机会:-)
通过Power Pack进行Code First迁移的一些优势：可以在C＃中执行更新任务，而不仅限于DDL / DML（可以方便），自动降级（尽管我质疑他们的使用），不需要购买第三方工具（可能很昂贵），更容易整合/部署到Azure SQL，与特定数据库供应商（理论上）的联系较少等。
虽然Code First迁移（以及这种自动化）对于绝对可怕的Drop-and-Recreate方法来说是一个很好的进步，但我更喜欢在开发时专用SQL工具。
链接地址: http://www.djcxy.com/p/90235.html上一篇: Migration using model first approach in entity framework
下一篇: How do I generate automatic migration scripts with model