I’m trying to find out a proper database development process in my applications. I’ve tried Visual Studio Database projects with Post/Pre deployment scripts (very nice feature), Entity Framework Database First approach (with separate script for each database change placed under source control), and now I’m dealing with Entity Framework Code First approach. I have to say that I’m really impressed with the possibilities that it gives, but I’m trying to figure out how to manage the changes in the models during the development. Assuming that I have the following environments in my company:
LOCALHOST – for each single developer,
TEST – single machine with SQL Server database for testing purposes,
PRODUCTION – single machine with SQL Server database used by clients
Now each time when I’m working on an application and the code changes, it’s ok for me to drop and recreate the database each time when I’m testing an application (so for LOCALHOST and TEST environments). I’ve created proper database initializers that seeds the database with test data and I’m pretty happy with them.
However with each new build when model changes, I want to handle the PRODUCTION database changes in such a way that I won’t lost the whole data. So, in Visual Studio 2012 there is the “SQL Schema Compare” tool and I’m just wondering if it is not enough to manage all changes in the database for PRODUCTION development? I can compare my {local} database schema with PRODUCTION schema and simply apply all changes?
Now, I want to ask what’s the point of Code First Migrations here? Why should I manage all changes in the database through it? The only reason I can find is to allow to perform all sort of “INSERT” and “UPDATE” commands. However I think that if database is correctly designed there shouldn’t be such need to perform these commands. (It’s topic for another discussion so I don’t want to go into details). Anyway I want to ask – what are the real advantages of Code First Migrations over the Code First + Schema Compare pattern?
It simplifies deployment. If you didn’t manage the migrations in code, then you would have to run the appropriate delta scripts manually on your production environment. With EF migrations, you can configure your application to migrate the database automatically to the latest version on start up.
Typically, before EF migrations, if you wanted to automate this you would either have to run the appropriate delta scripts during a custom installation routine, or write some infrastructure into your application which runs the delta scripts in code. This would need to know the current database version, so that it knows which of the scripts to run, which you would normally have in a DbVersion table or something similar. With EF migrations, this plumbing is already in place for you.
Using migrations means the alignment of model and database changes is automated and therefore easier to manage.