Stored procedures/DB schema in source control

Question

Do you guys keep track of stored procedures and database schema in your source control system of choice?

When you make a change (add a table, update an stored proc,

Answer 1

We store everything related to an application in our SCM. The DB scripts are generally stored in their own project, but are treated just like any other code... design, implement, test, commit.

Answer 2

I highly recommend maintaining schema and stored procedures in source control.

Keeping stored procedures versioned allows them to be rolled back when determined to be problematic.

Schema is a less obvious answer depending on what you mean. It is very useful to maintain the SQL that defines your tables in source control, for duplicating environments (prod/dev/user etc.).

Answer 3

We do keep stored procedures in source control. The way we (or at least I) do it is add a folder to my project, add a file for each SP and manually copy, paste the code into it. So when I change the SP, I manually need to change the file the source control.

I'd be interested to hear if people can do this automatically.

Answer 4

One thing to keep in mind with your drop/create scripts in SQL Server is that object-level permissions will be lost. We changed our standard to use ALTER scripts instead, which maintains those permissions.

There are a few other caveats, like the fact that dropping an object drops the dependency records used by sp_depends, and creating the object only creates the dependencies for that object. So if you drop/create a view, sp_depends will no longer know of any objects referencing that view.

Moral of the story, use ALTER scripts.

Answer 5

Stored procedures get 1 file per sp with the standard if exist drop/create statements at the top. Views and functions also get their own files so they are easier to version and reuse.

Schema is all 1 script to begin with then we'll do version changes.

All of this is stored in a visual studio database project connected to TFS (@ work or VisualSVN Server @ home for personal stuff) with a folder structure as follows:
- project
-- functions
-- schema
-- stored procedures
-- views

Answer 6

If you're looking for an easy, ready-made solution, our Sql Historian system uses a background process to automatically synchronizes DDL changes to TFS or SVN, transparent to anyone making changes on the database. In my experience, the big problem is maintaining the code in source control with what was changed on your server--and that's because usually you have to rely on people (developers, even!) to change their workflow and remember to check in their changes after they've already made it on the server. Putting that burden on a machine makes everyone's life easier.