我正在开发一个系统，该系统目前有许多环境（测试，舞台，现场等），每个环境都有自己的数据库。到目前为止，这些数据库通过在每个数据库上运行相同的更新脚本来保持同步。
我们现在正在转向使用EF6代码首次迁移，并且还想开始使用LocalDB编写一些自动系统测试。
我找到了https://msdn.microsoft.com/pt-pt/data/dn579398，其中介绍了添加初始迁移的两个选项。
第一种方法创建一个空的初始迁移，这对于现有环境非常有用，但不会帮助创建用于测试的LocalDB。
第二种方法创建了一个迁移，从头开始调整整个数据库（减去EF不关心诸如sprocs和views之类的东西）。这对于测试来说是可以接受的，但对于实际重新创建数据库并不好。它还要求您手动注释掉Up方法，在所有现有数据库上运行迁移，然后重新启动Up方法。由于需要一段时间才能通过所有环境进行迁移，所以我并不热衷于此。它也违反了迁移原则之一，即它们一旦被释放就不应该被编辑。
在迁移中有某种条件可以解决我的问题（例如，如果（tableExists（＆＃34; A_table_in_the_existing_database＆＃34;）返回;）但似乎没有那样可用。
我提出的最好的方法是将现有的数据库模式从SQL服务器转储到文件（具有保留sprocs，视图等的优点），然后使用上面的选项2，除了使用生成的Up方法我将运行SQL文件。
然而，这仍然具有上述选项2的缺点，因此我非常乐意了解处理这种情况的更好方法。
修改 这会有用吗？在一个数据库上运行注释掉的初始迁移，然后转出__MigrationHistory表并将其插入其他数据库？这样我就不必等待迁移才能通过所有环境，然后才能安全取消注释。
答案 0 :(得分：1)
EF 6.1.2支持在包含使用SqlResource方法的迁移的程序集中运行作为资源嵌入的SQL。
我认为我会编写现有架构的脚本并使用执行SqlResource作为其Up的初始迁移。如果他们所做的只是一堆IF EXISTS那么它就不会花费太长时间来运行。否则，如果您只想在本地运行脚本并将其应用于所有其他数据库，脚本__MigrationHistory也可以正常工作。