是否确定更新EF迁移的生产数据库？ [英] Is it OK to update a production database with EF migrations?

问题描述

根据这篇博客使用EF迁移大多数公司都理应没有更新的生产数据库与EF迁移数据库模式。相反，博客文章的作者建议使用架构更新脚本作为部署过程的一部分。

According to this blog post most companies using EF Migrations are supposedly not updating the database schema of production databases with EF migrations. Instead the blog post's author recommends to use Schema update scripts as part of the deployment process.

我用架构更新脚本几年了，虽然他们的工作，我计划在将来使用EF迁移，而不是出于以下原因：

I've used Schema update scripts for a few years now and while they work, I was planning to use EF migrations instead in the future for the following reasons:

• 部署更快，停机时间更短


• 一个更简单的部署过程


• 比现有的数据容易得多迁移将有可能与T-SQL


• 要应用的变化等待一个更易于理解的语法（DbMigration类清洁C＃语法与笨重的T-在传统的环境中的SQL迁移脚本）。


• 有一个简单，快捷的降级路径旧数据库架构，如果新的软件版本的部署应该失败

• Faster deployment, less downtime
• A simpler deployment procedure
• Much easier migration of existing data than it would be possible with T-SQL
• A more comprehensible syntax of the changes waiting to be applied (DbMigration class with clean C# syntax vs. clunky T-SQL Migration script in a traditional environment).
• There is an easy and fast downgrade path to the old db schema if the deployment of the new software version should fail

一个原因，我能想到的，将禁止使用EF的迁移生产DB是，如果DB模式仅由DBA的改变相对于开发人员。然而，我既DBA和开发人员，所以这并不在我的情况无关紧要。

One reason I can think of that would prohibit the use of EF to migrate a production DB would be if the DB schema was only altered by the DBAs as opposed to the Developers. However, I am both DBA and Developer, so this does not matter in my case.

那么，什么是更新使用EF生产数据库的风险？

So, what are the risks of updating a production database using EF?

编辑：我想补充的是，作为solomon8718已经建议，我总是拉着生产数据库的最新副本到我的临时服务器和测试EF迁移到适用于临时服务器之前将其应用到生产服务器。 IMO这是任何架构更新到生产系统的关键，我是否使用EF迁移与否。

I would like to add that, as solomon8718 already suggested, I am always pulling a fresh copy of the production database to my staging server and test the EF Migrations to be applied on the staging server before applying them to a production server. IMO this is essential for any schema update to a production system, whether I'm using EF migrations or not.

推荐答案

好吧，我会尽力回答，无论如何。我会说没有，我们没有理由不使用的Code First迁移生产。毕竟，这是什么易于使用的系统的点，如果你不能把它所有的方式？

Well, I'll try and answer anyhow. I would say No, there's no reason not to use Code First Migrations in production. After all, what's the point of this easy to use system if you can't take it all the way?

我看到它最大的问题是，你可以与任何系统，你已经提到的所有问题。只要整个团队（包括DBA如适用）在船上用它，我觉得让EF通过迁移管理架构是那么复杂，因此不易出错比传统的基于脚本的管理。我仍然会做备份，在生产系统上执行迁移之前，但随后你会做到这一点无论如何。

The biggest problems I see with it are all problems that you can have with any system, which you've noted already. As long as the whole team (DBA included if applicable) is on board with it, I think allowing EF to manage the schema through migrations is less complex, and hence less error-prone than traditional script-based management. I would still take a backup before performing a migration on a production system, but then you'd do that anyhow.

有什么，说一个DBA不能从Visual Studio执行迁移，无论是。访问仍然可以使用权限在数据库级别前锁定，他/她可以（使用 -Script 在一个有用的SQL导出格式，如果需要的话）查看迁移执行实际的操作。然后，他们仍然在控制，但是你可以使用代码优先迁移。 ！地狱，他们甚至可能最终会喜欢它。

There's nothing that says a DBA can't perform a migration from Visual Studio, either. The access could still be locked down with privileges at the database level, and he/she could review the migration (in a helpful SQL export format using -Script, if desired) before performing the actual operation. Then they're still in control, but you can use code-first migrations. Hell, they might even end up liking it!

更​​新：由于存储过程和TVFs长大了，我们处理那些迁移，以及，虽然他们实际上是直做使用在 DbMigration.Sql（）通话-UP SQL语句向上（），其中在反在向下（）（您也可以使用 CreateStoredProcedure 和 DropStoredProcedure 简单的存储过程，但我认为你还是要确定身体本身的SQL）。我想你可以说这是一个警告;目前还没有一个完整的，全面的数据库是在C＃编写纯粹的方式。然而，你的可以的使用迁移，其中包括SQL脚本来管理整个架构。我们从这个过程中发现的一个好处是你可以用一个简单的的String.Format ，为配置文件本身具有XML转换相结合。

Update: since SPROCs and TVFs were brought up, we handle those in migrations as well, although they are actually done with straight-up SQL statements using a DbMigration.Sql() call in the Up(), and the reverse of them in the Down() (You can also use CreateStoredProcedure and DropStoredProcedure for simple SPROCs, but I think you still have to define the body itself in SQL). I guess you could say that's a caveat; there isn't yet a way for an entire, comprehensive database to be written purely in C#. However, you can use migrations which include SQL scripts to manage the entire schema. One benefit we've found from this process is you can use the C# config file for schema object names (different server names for production vs dev for example) with a simple String.Format, combined with XML Transformation for the config files themselves.

这篇关于是否确定更新EF迁移的生产数据库？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！