Hi everyone!
I am familar with the fact that Visual Studio has Database projects that allow you to manage database changes.
I've used the processes outlined here in the past with success: http://www.ssw.com.au/SSW/Standards/Rules/DataSchemaStandard.aspx. This approach uses the "Create Scripts" and "Change Scripts" folders that the Database project creates for you. So you end up creating a new file anytime there are database changes. This file also has a bit of code that updates a table which tracks the changes that have been applied. It's a pretty neat approach for being able to tell what has been applied to a database and what state it is in. Almost kind of like a release number.
And I've also this 4Guys article (http://aspnet.4guysfromrolla.com/articles/071305-1.aspx). In it Scott recommends using separate folders for the different database objects (tables, stored procedures, etc.) and then version controlling the specific objects. It seems to me that this approach actually ties in better with a source control (a stored procedure has a history).
While the approach in the SSW article is great, I think it is somewhat less necessary with tools like SQL Compare and is the reason why I think that the 4Guys article might be better now.
Can anyone point me to any articles or books (we have books24x7) outlining how databases are managed and tied in with TFS? Given that the articles above are several years old, I would think that the strategies have probably been clarified in TFS.
Thanks!
