>>>>
>>>>I would recommend looking at the Code-First methodology and getting familiar with EF Migrations.
>>>
>>>Why ? in the bigger gigs that is a no-no over here. DB first and DBA has aways last word...
>>
>>I mentioned to Mike earlier I see why code-first is kind of cool, but I'm trying visualize a team of n developers working on a project using migrations. Seems find for prototyping but I can't imagine DBAs what are basically developer driven autoscripts.
>>
>>That said, I think there is a provision in code first for creating scripts rather than actually running them on the back end so I'm sure there is a way it will become part of the EF-DBA environment.
>>
>>But I'm not drawn to it right now as a big time saver. Even as a single developer I'd rather fiddle the database in SSMS ( or even the datatools in VS) and fiddle the code separately as kind of a double-check if nothing else.
>
>It works well if you have a continous integration environment. When I want to roll code to prod, I simply merge my changes into the prod branch. Teamcity monitors that and automatically rolls out changes and runs migrations. It takes the ceremony out of rolling out, so I can turn tasks around quicker.
>
>And like I mentioned, you really have to buy into the "db is only persistence" mentality. Yeah, you're never going to probably get to the place where you don't need to take advantage of specific DB features, but I've been more productive this way. I don't care about table names, field names, normalization... I just care about crafting rich models in my code and letting EF handle the persistence. Of course I need to add indexes and refactor grids/reports to stored procedures if there's performance issues, but those are afterthoughts now.

Sounds like I have a lot of stuff to learn here. Cool ! When I get a little further along with my understanding of enterprise level EF (bless you Julie) I think I will start picking your brain - or come looking for a job :-)