Question

I’ve started looking into Entity Framework migrations on 4.3.1. Have a few questions:

1. What’s preferred during development? Why should I not just drop and recreate my
   database always and then reseed. If I use code first migrations, can
   I choose to seed my db initially and then add a seed method to each
   migration to only add in new data? If i use automatic migrations, is
   it possible to do something similar? i.e. seed initially and then
   seed as required?

2. What is the benefit of using migrations during development? I only
   actually need migrations when moving to production. So, I need to
   create my initial script and then scripts for each migration, so
   would it be possible to only use migrations once i want to move to
   production and at that point create an initial script and maintain a
   migration history from that point onwards?

Answer 1

Well, in our case, we started to use Migrations because in our company, devs don’t have the necessary rights to create a DB, which lead to the amusing scenario where I dropped the DB a couple of times and had to ask the db admin to recreate it each time…
In my opinion, it seems easier to incrementally grow your DB, rather than having to recreate it each time. If I were to have to drop and recreate our DB every time a property is added, deleted or changed, I’d never see the end of it.

I’ve not yet seen a possibility for incremental seeds, unless perhaps if you create manual migration files.
Migrations has the possibility to go to a specific version (either forwards or backwards) and it is possible to generate an SQL script from a migration.
So basically, you don’t have to create a migration SQL script by hand anymore, you can get Migrations to do it for you.