在我公司，我们目前更新数据库的方法是使用 VS2005 中的服务器资源管理器进行连接，然后通过打开和编辑来修改存储过程。这里的开发人员似乎很享受“像代码一样编写和保存它”的心态。非常方便，当我们需要调整某些内容时，它如何自动将 Create 转换为 Alter 并针对现有数据库运行脚本。
最近，在服务器崩溃期间，当我们丢失了很多没有备份的更改时，这让我们非常难过。我正在推动将我们的 SQL 开发移到它所属的位置：在 DB 项目中，以便我们可以将它们与其他代码一起放入 SVN。另一种方法是每晚备份数据库。
不过，我不太了解数据库项目，也不了解它们的工作流程。恐怕如果我无法获得与他们当前模型类似的实用程序，他们就不会切换。关于维护我们当前的工作模型，但切换到 DB 项目的任何想法？
如果开发人员制定了规则（并且您的帖子听起来像他们这样做），那么您只能在新的工作流程对他们“更好”的情况下继续。作为一名开发人员，我认为这就是应该的方式。我见过一些非开发人员想出一些非常荒谬的开发过程，并强迫他们去开发人员，从而损害每个人的利益。
如果您正在考虑 VS DB 项目，您首先要测试 VS DB 是否真的适用于您的数据库。如果是这样，您将不得不在过程中设置一个很大的机会：数据库的“真实”副本现在位于 VS DB 而不是数据库服务器中。
另一种方法是定期备份开发服务器。如果您每天备份它，并且每小时备份一次事务日志，则很难丢失大量工作。
或者创建一个将整个数据库定义写入文本文件的计划作业。（为数据库中的所有对象编写脚本。）这些文件通常非常小，因此您可以保留很长的积压。
许多受人尊敬的博主似乎认为在 SVN 中存储数据库定义是一个好主意。请参阅此编码恐怖帖子或相关的 Stack Overflow 相关问题How do I version my MS SQL database in SVN。
与开发人员讨论，看看你能达成什么共识。