>>>
>>>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 fine for prototyping but I can't imagine DBAs warming up to what are basically developer driven autoscripts. It is not the creation done by codefirst on first pass that is the issue but keeping the backend in sync in a production environment. If you have a deployed database and are still developing the app, you are hopefully migrating to a dev server. you are going to need script to go to a staging server or production server anyway.
>
>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.

Beginning around 1995 SBT had a built in data dictionary system that handled the updates to the physical DB from schema tables, including indexes. Later, it handled SQL Server.
It was really handy. Instead of making changes to production DB's (that always scares me) we sent the dictionary changes and let the dictionary routines update the DB.
I've thought several times of building one myself, but it never seems to get to the top of the list.
EF seems to have that built in.