如何处理实体框架中的数据库更改
我使用 codefirst 并发布了我的应用程序的 1.0 版本。
现在我更改了一堆表内容，并且想将应用程序的 1.0 db 升级为 2.0。
在实体框架中通常如何处理这种情况？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
我使用 codefirst 并发布了我的应用程序的 1.0 版本。
现在我更改了一堆表内容，并且想将应用程序的 1.0 db 升级为 2.0。
在实体框架中通常如何处理这种情况？
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（2）
EF 尚未内置任何用于生成 diff 脚本的内容。 EF 可以删除并重新创建数据库，但这在现实世界中并不是真正可用......他们似乎有数据库迁移计划，但我不知道何时/是否可用（ http://blogs.msdn .com/b/efdesign/archive/2010/10/22/code-first-database-evolution-aka-migrations.aspx）。
如果您想要进行增量更改（添加/删除表、列、约束、索引等），则必须编写 SQL 脚本来应用从版本 1 数据库到版本 2 数据库所需的更改。在数据库中的某个位置存储数据库“版本号”可能是一个好主意，这样当您“在野外”运行多个不同版本时，可以更轻松地应用正确的脚本。
或者，有第 3 方工具可以基于 EDMX/db diff 生成增量 diff 脚本（“alter table ...”等），例如我的 EF4 的“模型比较器”： http://huagati.blogspot.com/2010/07/introducing-model-comparer-for-entity.html
EF doesn't have anything built-in for generating diff scripts [yet]. EF can drop and recreate the DB but that is not really usable in the real world... ...they seem to have plans for db migrations, but I don't know when/if that will be available ( http://blogs.msdn.com/b/efdesign/archive/2010/10/22/code-first-database-evolution-aka-migrations.aspx ).
If you want to make incremental changes (add/drop tables, columns, constraints, indexes etc), you will have to write SQL scripts that applies the changes needed to go from your version 1 DB to your version 2 db. It can be a good idea to store a db "version number" somewhere in the database to make it easier to apply the right scripts when you have a number of different versions running out "in the wild".
Alternatively there are 3rd party tools that can generate incremental diff scripts ("alter table ... " etc) based on EDMX/db diffs, e.g. my 'Model Comparer' for EF4: http://huagati.blogspot.com/2010/07/introducing-model-comparer-for-entity.html
我们使用的一种替代方案是保留两个实体框架模型，一个是旧的，一个是新的。在反射的帮助下，您可以创建最适合的迁移算法。
旧的 EF 模型可以序列化为 XML 或任何此类格式。然后，您可以删除并重新创建数据库，并从 XML 反序列化您的 EF 模型，并将它们放回新数据库中。然而，插入身份似乎没有什么问题，但它是可以管理的。
但此解决方案仅适用于小型数据库，对于较大的数据库，您将需要更高级的解决方案。
One alternative we are using is keep two entity framework model, one with old and one with new. And with help of reflection, you can create a migration algorithm that suites best.
Old EF model can be serialized to XML or any such format. And you can then drop and recreate database and deserialize your EF model from XML and put them back in new DB. However there seems little issue with inserting identity but it can be managed.
But this solution is only for small database for larger databases you will need more advanced solution.