Source Control tools for Visual Studio 2010 and SQL Server 2008 scripts and database updates?

Question

We are currently using Visual Studio 2010 and SQL Server 2008 R2 - developing intranet ASP.NET applications that use (several) SQL Server databases.

We have been storing

Answer 1

One additional factor or criteria you may want to consider is where you and your team are most comfortable writing your scripts \ stored procedures, etc.

We've evaluated Visual Studio Team Database Edition (or whatever it is currently called these days) in the past and came to the unfortunate conclusion that we just were not comfortable and happy writing SQL from within Visual Studio. We're much more productive as a team writing SQL using SSMS. You of course might find the opposite to be true.

We're also in the middle of evaluating Red-Gate's SQL Source Control tool. The biggest plus for us is that it works within SSMS and is relatively frictionless. For whatever reason, their model maps a bit better to how we tend to do SQL development work.

Regarding deployment, both products appear to skew slightly more towards development work where you are deploying changes to a database that is on your servers. From an ISV standpoint this makes it a bit more challenging to generate deployment scripts to be executed on a database outside of you environment (e.g. database hosted on a client's server).

For that reason, I personally like the approach Microsoft has taken where you can generate a schema file which describes the schema of the database. I'm probably leaving something out, but I recall that this schema file is what is used to generate the scripts to update a target database. The beauty of this solution is that the change scripts could be different depending upon the state of the target database.

Unfortunately, if you don't have "DBPro" available (again, think client site for a moment) you're left with using VSDBCMD to generate the change scripts from the schema file. While this works, it would be nice if Microsoft exposed an API for VSDBCMD so one could create a GUI to make it easier for non-developer types to execute rather than having to use a command line tool.

It's difficult to imagine that VS Team Database Edition won't gain additional features in the future, so betting on MS probably isn't really a gamble assuming of course you can live with the present shortcomings of the tool.

Answer 2

You don't integrate source control into database as such.

It isn't file based. Your database consists of tables, code, data, indexes, statistics, security etc: these all live in system tables.

Rather the copy+paste, see my previous answers...

• Is RedGate SQL Source Control for me?
• Exposing SQL Server database objects as files in a file system

We follow Martin Fowler's "Evolutionary Database Design" more or less

Answer 3

My Org has been using both for two different projects, and I have become very partial to the RedGate tools. As you mention to get the full functionality you need the whole toolset from RedGate, but you get a lot of extras with that as well (including refactoring, or global search/replacing). For syncing of DEV to TEST/QA/PROD environments I use their Compare products to build out sets of scripts (which generally require further review). I don't really trust any tool to update an in-use schema unless I'm prepared to quickly restore it.

In contrast I found the MS tools to be overly complicated, which made them somewhat inflexible. We found ourselves in a pickle when we had some changes in the DB that needed to be synced to the project, but changes in the project that wouldn't allow it to be built without the changes from the DB... it ended up in a whole catch-22 scenario that required a LOT of manual editing (and resulted in testing and purchase of the RedGate tools).