Managing database scripts in your solutions

Question

I usually create a solution folder in Visual Studio and put my DB scripts in them. I always use at least this set of scripts:

1. Drop model
2. Create model script
3. User functions
4. Stored procedures
5. Static data (lookup tables)
6. Test data (not deployed)

Then I simply combine them and run against an SQL Server so I'm able to recreate the whole DB in a single step (by combining these scripts into a single one and executing it).

Anyway. I've never used projects in either:

• Visual Studio or
• SQL Management Studio

I've tried creating SQL Server 2008 Database Project in Visual Studio 2010, but I'm somehow overwhelmed by all the possible server settings (which I prefer to stay default as set on the server anyway). So I'm a bit confused: Should I use this project template or should I just do the same thing I always did?

What do you use and why? What are advantages I may benefit from by using either?

Answer 1

If I were you I would continue to do it the way you are doing it. In fact I do! The advantages of having the actual .sql files right there in a folder for you to use/edit/look at in my opinion are far better than the advantages you get by using a DB project. DB Project would be used if you were doing something like Storage Reports, were you have to communicate with like 8 databases and compare then to 8 different databases and save result sets etc... Now don't get my wrong there are advantages of Database Projects, I just don't think they are actually doing much help when you have such a simple setup that works already.

Advantages of the SQL Server 2008 Database Project in VS10:

• Not having to switch back and forth from your current client you use to communicate with your SQL server.
• Decent Data and Schema compare tools.
• Gives you a one-click way to reverse engineer a database into source control, and keep it up to date.
• You can compare projects to physical databases and vice-versa. (This makes it pretty easy to keep your database up to date, no matter where you make change it: file system database project, or in the physical database itself)
• If the current tool your using is not specifically tailored to SQL Server, this one is.
• Extremely helpful if you need to do unit tests directly on the database without using abstractions.

Answer 2

If you're looking for something a little less complicated, you might want to try SQL Source Control. This won't even require you to maintain scripts, as it doesn't this for you behind the scenes. It will, however, only work as a solution for you if you use either TFS or SVN. And it costs $295...

It has a 28-day trial period, so if you're happy to try it out, I'd be interested in your feedback.