>>>That said, as I was reading some Julie Lehrman stuff today on EF Code First and doing a walkthrough on the much needed Migrations that are in EF 4.3 caught myself thinking that I had become so comfortable now with TSQL and thinking in terms of workning directly on the backend that while some of the codefirst or even model first stuff is cool, I am still drawn to maintaining DB schema in the database and pushing up to the EF from there.
>>
>>It is cool only because so much automation is in place. But for me conceptually DD/schema based is clearly superior.
>>Firmly on Hank's side on this - even if nearly all current fwk/ORM does it the other way.
>
>Strataframe has a very nice SMO based tool called DataDeploymentToolkit which can crate packages that will update schema, sps etc along with deployment of app that requires the changes. I like it a lot as it integrates with the business objects in the framework such that you know if the BOs work in your app the package will put the database in a state to work with the changes when you deploy.
>
>Perhaps the database migration stuff in EF ( or some third party add on for it ) will get there some day but right now the whole code first thing seems more trouble than it is worth for SQL Server back ends.

SMO: shows the plus side of a fwk - if you can stay inside Dotnet...
It is not only the Dotnet stuff: almost every web fwk (RoR, Django...) works that way as well,
having/mentioning database first only for existing DB or dinosaurs, if at all.

Code first has the benefit of better integration with source control,
whereas DD/schema based sometimes resorts to YAML or other kludge.

>Of course I was joking about the attitude. Actually I am insecure enough to hate the idea that *anybody* would come in after me, look at what I had done and be anything less than awed. <s> Besides, I want to be called back for new stuff because they are so happy, not dragged back in chains forged by their lawyers <g>

Does not want to crack lawyer heads! Primadonna ;-)

regards

thomas