为什么使用实体框架迁移答案

【问题标题】：Why use Entity framework Migrations为什么使用实体框架迁移
【发布时间】：2012-08-17 16:11:59
【问题描述】：

我已经开始研究 4.3.1 上的实体框架迁移。有几个问题：

在开发过程中首选什么？为什么我不应该放弃并重新创建我的数据库总是然后重新播种。如果我使用代码优先迁移，可以我选择最初为我的数据库播种，然后为每个数据库添加一个种子方法迁移只添加新数据？如果我使用自动迁移，是有可能做类似的事情吗？即先播种，然后播种按需播种？
在开发过程中使用迁移有什么好处？我只是迁移到生产环境时实际上需要迁移。所以，我需要创建我的初始脚本，然后为每次迁移创建脚本，所以一旦我想搬到那里，是否可以只使用迁移生产，然后创建一个初始脚本并维护一个从那时起的迁移历史？

【问题讨论】：

【解决方案1】：

嗯，在我们的例子中，我们开始使用迁移，因为在我们公司，开发人员没有创建数据库的必要权限，这导致了一个有趣的场景，我放弃了几次数据库，不得不要求数据库管理员每次重新创建它...
在我看来，增量增长数据库似乎更容易，而不是每次都重新创建它。如果每次添加、删除或更改属性时我都必须删除并重新创建我们的数据库，我永远不会看到它的结束。

我还没有看到增量种子的可能性，除非您创建手动迁移文件。
迁移可以转到特定版本（向前或向后），并且可以从迁移中生成 SQL 脚本。
所以基本上，您不必再手动创建迁移 SQL 脚本，您可以让 Migrations 为您完成。

【讨论】：

谢谢！这似乎是一个很酷的功能，我只是不愿意在我的开发环境中使用迁移，因为它在每次更新时运行种子方法，所以我的数据是重复的。我可以使用 AddorUpdate，但从我所读的内容来看，这似乎有其自身的问题，这就是为什么删除和重新创建它似乎是最简单和最安全的原因。如果我们可以关闭种子方法或在每次迁移时运行多个种子方法，那就太好了。我假设解决此问题的一种方法是将 Sql(insert) 添加到我的迁移文件中......但是我的种子数据不在一个位置，有点混乱
是的，这确实很烦人。我们通过首先检查某个记录（通常会被播种）是否已经存在于数据库中，如果存在则中止播种，从而快速而肮脏地解决了这个问题。从我在其他 SO 帖子中读到的内容来看，如果您使用手动迁移，完全有可能增量播种。可以关闭种子：只是不要在种子方法中添加任何代码:-)
您可以使用 AddOrUpdate() 方法，该方法提供了一种简单的方法：)