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

SQL procs also surely need the same security/benefits of version control as the rest of the code in the project.

Answer 2

There are methods in SMO to generate scripts if you prefer to code your own scripting tool.

http://www.sqlteam.com/article/scripting-database-objects-using-smo-updated

Answer 3

If you're not using asset management alongside source control, then I say throw everything in source control. Images, word documents, the whole shebang. Can't lose it, can always reverse any changes to it and if any machine goes down - nothing is lost.

Answer 4

We store our procs in Subversion, all your SQL Code including DDL should be in some kind of source control repository

Answer 5

Get your database under version control. Check the series of posts by Scott Allen.

When it comes to version control, the database is often a second or even third-class citizen. From what I've seen, teams that would never think of writing code without version control in a million years-- and rightly so-- can somehow be completely oblivious to the need for version control around the critical databases their applications rely on. I don't know how you can call yourself a software engineer and maintain a straight face when your database isn't under exactly the same rigorous level of source control as the rest of your code. Don't let this happen to you. Get your database under version control.

Answer 6

Sure you should.

In MS SQL 2008, you can do it right from Management Studio.