Is there an alternative to Code First Migrations with EF when all code changes are done by a DBA?

Question

I\'ve read about Code First Migrations but it seems that this is not really suited to the Enterprise.

We have a DBA that does all our Database changes and we don\'t nee

Answer 1

Just to add a few thoughts on this - take a look at these two posts (I made a while ago): https://stackoverflow.com/a/10164815/417747
https://stackoverflow.com/a/10255051/417747

In short, from my experience:

• you can't easily 'maintain' such a solution in a real enterprise size Db. Sooner or later the 'two worlds' are going to collide, synchronizing things might be painful (though doable)
• however you shouldn't give up on it because of that. It's good for jump-starting and with careful planning, syncing you can make this work for a while,
• you can dump the scripts and / or tweak the migration code, adjust the 'seeding' - to do away with some changes (still some limitations are painful and I doubt it'd ever going to 'mimic' what DBA can do),
• you can skip the 'generation' from CF once it goes too far (pretty soon actually, as soon as DBA takes over) - and just (using scripts and partly explained in posts) make sure your Db-s match (real and 'code' blueprint one). That still means you have most of the tables etc. setup and you'd need to tweak some things,
• this is a 'rule of thumb', in good chunk of cases CF won't be plausible - so just use it for prototyping then,
• for scenarios you're describing a good 'db generator' is probably a better solution (but it has some downsides as well), but I still haven't seen a good 'combo' of both worlds

hope this helps a bit.