Versioning default install/customized triggers and stored procedures

I'm a developer at a small company where we're struggling for consistent change control. I'm running into issues where non-dev staff are tweaking stored procedure开发者_如何转开发s and triggers in production installations. Their changes are being overwritten when we apply upgrades because they've gone outside of the process the dev team uses to verify db changes are incorporated into source control.

How would you recommend approaching this problem from a technical as well as personal perspective?

Edit 1: A little background on our current process might help this along. We're using a continuous integration server (TeamCity) to generate install artifacts and label svn upon check in. I'm using NMigrations to manage schema and sp/trigger changes when we apply fixes. Unfortunately it's beyond my ability to stop unauthorized schema changes so what I would love to find is a design pattern that allows for an overridable trigger/sp definition.

You need to clearly separate:

• source control management
• release management

Tweaking in prod shouldn't be possible if the release environment is protected through strict ACL preventing anyone duly appointed to deploy and change stuff.
If that deployment process is automated, then all changes will go through the proper channel because anyone will known a simple "push button" process will be enough to deploy the hotfix.

But if getting that fix in source control and deploy it is complicated, then a tweak directly in prod is usually the result...

Limit rights to change stored procedures and triggers, especially on production. Go ahead and let them know first so they aren't blindsided, but clearly protect production from all unauthorized changes.