我觉得我的商店有一个漏洞,因为我们没有一个可靠的流程来版本化我们的数据库模式更改.我们做了很多备份,所以我们或多或少都被覆盖了,但以这种方式依赖你的最后一道防线是不好的做法.
令人惊讶的是,这似乎是一个共同点.我说过的很多商店都忽略了这个问题,因为他们的数据库并没有经常改变,而且他们基本上只是努力做到细致.
但是,我知道这个故事是怎么回事.事情排列错误只是一个时间问题而且缺少某些东西.
对此有什么最佳做法吗？有哪些策略对你有用？
我们的团队第一次遇到了没有版本控制的麻烦.我们如何才能将存储过程至少添加到版本控制中？我们正在开发的当前系统主要依赖于SP.
现在我们有一堆数据库服务器,其中运行的存储过程记录很少,并且不存在.
当对一个进行更改时,没有日志,并且很难弄清楚为什么突然失效的东西.
我们最近使用SVN切换到使用正确的版本控制,所以我希望将这些存储过程添加到版本控制中.
我们是.Net商店,我知道存在一个Database项目类型.这会是一个好方法吗？
或者,我可以将存储过程保存为文本文件并对其进行操作,但我想知道这样做所涉及的令人讨厌的部署步骤.
我一直在想如何将所有存储过程放在源代码控制下的SQL 2000上.
我们正在使用Subversion来处理所有正常的源代码,所以如果使用Subversion解决问题会很好.
你有什么想法？
更新16-02-2009:这是我用于导出所有存储过程的vbs脚本:
Set con = CreateObject("ADODB.Connection")
con.ConnectionString = "*** Database connection string here ***"
con.Open
Set rs = CreateObject("ADODB.RecordSet")
rs.ActiveConnection = con
strSQL = "SELECT ROUTINE_NAME, ROUTINE_DEFINITION " & _
"FROM INFORMATION_SCHEMA.routines " & _
"WHERE ROUTINE_NAME NOT LIKE 'dt_%' " & _
"ORDER BY 1"
Set fso = CreateObject("Scripting.FileSystemObject")
rs.Open strSQL
While Not rs.Eof
filename = rs("ROUTINE_NAME") & ".sql"
routineSQL = rs("ROUTINE_DEFINITION")
Set tf = fso.CreateTextFile(filename, True)
tf.Write routineSQL
tf.Close
set tf = Nothing
rs.MoveNext
Wend …