Should you store your SQL Stored Procedures in Source Control?

Question

When developing an application with lots of stored procedures, should you store them in some sort of source versioning system (such as source-safe, TFS, SVN)? If so, why? And is

Answer 1

As others have said, yes they should be.

I don't know of an easy way to do this with SQL Server Management Studio, but if you also use Visual Studio, database projects are a great way to manage this.

Answer 2

Most definitely.

Answer 3

You should.

To my knowledge, no such tool exists to automate this process. At least, five years ago, when I was considering building one, there didn't seem to be any competition.

Answer 4

SPs and table schemas for that matter are all assets that should be under version control. In a perfect world the DB would be built from scripts, including the test data, as part of your CI process. Even if that's not the case, having a DB/developer is a good model to follow. In that way new ideas can be tried out in a local sandbox without impacting everyone, once the change is tested it can be checked in.

Management Studio can be linked to source control, although I don't have experience of doing this. We've always tracked our SP/schema as files. Management studio can automatically generate change scripts, which are very useful, as table drop/recreate can be too heavy handed for any table that has data.

Answer 5

Absolutely. Positively.

A set of SPs is an interface, that is likely to be modified more frequently than structural changes. And because SPs contain business logic, changes should be stored in version control to track the modifications and adjustments to the logic.

Storing these in version control is a symptom of organizational maturity at a coding level, and is a best practice.