我已经安装在我所采取的模式第一种方法，因为它为我做更多的逻辑意义上的系统。 现在，当连我都在模型中的一些变化目前我做的是 -
问 ：主要的问题是很乏味，因为我从我的本地系统做到这一点，连接到我的督促数据库非常缓慢，有时我的视觉工作室也崩溃。 是否有一个更清洁的方式来做到这一点？ 这是自动化程度更高，使得我的笔记本电脑是不是在生产实例数据库迁移真正负责任？
您可以尝试数据库迁移配电板 -它允许创建更改脚本，而不是完整的数据库脚本，但背后确实像你一样用手相同的过程。 问题是，上述工具不能与EF5工作 。
不幸的是EF迁移目前不支持通过EDMX创建的模型。 迁移支持目前唯一代码第一种方法。
在一个模式的第一个设计我使用ApexSQL差异（很可能非常相似，展鹏的产品，或许有点便宜） - 一个很好的第三方工具更容易比VS数据库项目使用，并且很容易与脚本应用工具应用像回旋。
在模型首先方法使用它可以使用如在后述模型架构的Diff-Schema的模型的一个周期跟随模式优先的方法; 考虑这些准则/下面的注意事项，以使一个精简的过程。 架构-DIFF方法并不需要是乏味，缓慢，或过度手册。
数据库模式的当前版本通过施加数据库补丁 （或DDL / DML脚本） 的序列获得。
一种工具（我们使用的回旋）根据需要自动应用脚本。 它记录的信息来知道哪些脚本已经被应用。 将同样的脚本是幂等。
DIFF针对本地数据库进行; 这个本地数据库可以从所有以自动化方式之前所做的更改脚本来建立。 这个最新的本地始终是最新型号的变化差异的目标。
远程/现场数据库从不用作DIFF目标 。 同样的脚本可以在以后应用于测试（再住）数据库。 因为一切都做同样的方式那么这个过程是对所有数据库重复。
唯一的“问题”是未经过深思熟虑的更新可能会导致该是在新的限制/约束无效数据。 当然，这是很容易识别，修复，并推到实时数据库之前重新差异。
一旦DIFF致力于源代码控制， 必须在树枝上应用。 “撤销”先前提交的变化，脚本需要创建应用反行动的新差异。 有没有隐式的向下的版本。
我们有情感上充当架构锁，必须统一反对[汞]模型分支; 这可以被看作是一个弱点，但它与小团队开发运作良好。
像Huagati DBML / EDMX的工具是用来架构同步回开发时，这是非常有用的模型。 这个小宝石真的为自己支付，并且是循环的一部分。 当这种采用很容易也“更新模型”或进行架构更改SSMS中（或其他），然后把他们带回来了。
该代码首先迁移是“OK”（绝对不是前功尽弃更好！），但我只使用它们，因为SQL Azure的（又名SQL数据库）不被先进的工装DIFF支持，由于没有暴露的各种SYS信息。 （该diff文件可在本地完成按正常，但ApexSQL Diff，产生DDL / DML并不总是与SQL Azure的友好 - 加，这是一个机会，我学到了稍微不同的方法:-)
通过电源包的Code First迁移的一些优点：可以在C＃中执行的，而不是被限制在DDL / DML（可以很方便），自动降级更新任务（虽然我怀疑他们使用），并不需要购买第三方工具（可以是昂贵的），更易于集成/部署到Azure的SQL，较少依赖于特定的数据库供应商（理论上），等等。
虽然代码优先迁移（以及这些自动化）是向前迈出的很好的一步对绝对可怕的投递和重新创建的做法，我更喜欢开发时奉献SQL工具。
