How should I share TSQL scripts in an ASP.NET MVC 4 web application project using (localDB)?

Question

I'm working with multiple developers on a web application project. Ideally, we'd have a development SQL Server set up but we are currently constrained to working with (localDB)\v11.0. I created and populated the database and sent the .mdf and .ldf files to my teammates (we do not want to commit it to a repository because .mdf and .ldf files changes every time from running debug).

Updates to the database are very infrequent. But I see a need to be able to create new views or add constraints every so often. I currently do this by running a T-SQL script on my (localDB) and re-sending the .mdf and .ldf files to my teammates.

What I need is a convention that dictates where I should save T-SQL scripts in my project so that my teammates, upon pulling new T-SQL scripts from the repository, are expected to run it against their (localDB) to keep it in sync.

In the past, I've worked with PHP projects where MYSQL files are saved in a sql folder, named by dates i.e. xx-xx-xxxx.sql. And everyday, a developer would run it against the development database. Are there similar conventions in an ASP.NET MVC 4 project (which I am not familiar with) for me to facilitate this process?

Having read http://msdn.microsoft.com/en-us/library/ex526337%28v=vs.100%29.aspx none of the asp.net folders sounds suitable for my purpose.

Answer 1

I think the best approach is to have a separated Database Project so each developer could add DML/DDL scripts to it and synchronize by deploying the project in the local databases. You can even Reverse engineering your database into a Database Project.

Note that Visual Studio 2010 had Database Projects to design, develop and deploy databases. In Visual Studio 2012 this was overhauled and is now part of SSDT (SQL Server Data Tools).

Also, SSDT can be installed as an extension in VS2010.

These are the main features of both:

• Source control the database
• Schema syntax
• Ease of refactoring
• Automatic generation of deployment scripts
• Centralized development