我们的团队第一次遇到了没有版本控制数据库麻烦的麻烦。我们如何才能将存储过程至少添加到版本控制中?我们正在开发的当前系统主要依赖于SP。
答案 0 :(得分:20)
背景:我开发了一个拥有近2000个存储过程的系统。
我发现的关键是将数据库视为一个应用程序。您永远不会直接使用十六进制编辑器打开EXE并进行编辑。与数据库相同;只是因为你可以从数据库编辑存储过程并不意味着你应该。
将源代码管理中存储过程的副本视为 当前版本。这是你的源代码。检查,编辑,测试,安装,然后重新检查。下次必须更改时,请按照相同的步骤进行操作。就像应用程序需要构建和部署过程一样,存储过程也是如此。
以下代码是此流程的良好存储过程模板。它处理更新(ALTER
)或新安装(CREATE
)的两种情况。
IF EXISTS(SELECT name
FROM sysobjects
WHERE name = 'MyProc' AND type = 'P' AND uid = '1')
DROP PROCEDURE dbo.MyProc
GO
CREATE PROCEDURE dbo.MyProc
AS
GO
但是,在您控制对存储过程的访问权限的情况下,以下示例更好。 DROP
- CREATE
方法会丢失GRANT
信息。
IF NOT EXISTS(SELECT name
FROM sysobjects
WHERE name = 'MyProc' AND type = 'P' AND uid = '1')
CREATE PROCEDURE dbo.MyProc
AS
PRINT 'No Op'
GO
ALTER PROCEDURE dbo.MyProc
AS
GO
此外,创建一个完全从源代码控制构建数据库的过程可以帮助控制事物。
从源代码管理创建新数据库。 使用Red Gate SQL Compare之类的工具来比较两个数据库并识别差异。 调和差异。
更便宜的解决方案是简单地使用SQL Management Studio的“脚本为”功能并进行文本比较。但是,此方法对SSMS用于格式化提取的SQL的确切方法非常敏感。
答案 1 :(得分:5)
我肯定会推荐一些集成到SSMS中的第三方工具。除了上面提到的SQL Source Control之外,您还可以尝试使用Apex中的SQL Version。
重要的是,如果您希望开发人员使用它,那么这对开发人员来说非常容易,最好的方法是使用集成到SSMS中的工具。
答案 2 :(得分:3)
我认为将每个存储过程编写为单独的.sql文件然后将这些文件提交到源代码控制中是件好事。每次更改sproc时,都要更新创建脚本 - 这将以sproc为基础为您提供完整的版本历史记录。
有一些SQL Server源代码控制工具可以挂钩到SSMS,但我认为它们只是编写db对象的脚本并提交这些脚本。例如,红门看起来应该是今年的releasing such a tool。
答案 3 :(得分:1)
我们只是在.sql文件中将CREATE
语句添加到源代码控制中,例如:
-- p_my_sp.sql
CREATE PROCEDURE p_my_sp
AS
-- Procedure
确保每个文件只放置一个SP,并且文件名与过程名称完全匹配(这样可以更容易地在源代码管理中找到该过程)
然后,您只需要对未将源存储过程应用于数据库而不是来自源代码管理的行为保持纪律处分。
另一种方法是将SP保存为ALTER
语句 - 这样做的好处是可以更容易地更新现有数据库,但这意味着您需要进行一些调整以创建新的空数据库。
答案 4 :(得分:1)
出于这个目的,我一直在使用这个工具http://timabell.github.com/sqlHawk/。
确保没有人忘记检查更新的.sql文件的方法是让你的构建服务器强制登台和实时环境匹配源代码控制;-)(这个工具将帮助你)。
答案 5 :(得分:1)
IF NOT EXISTS(SELECT name FROM sysobjects
WHERE name = '<Stored Proc Name>' AND type = 'P' AND uid = '1')
EXEC sp_executesql N'CREATE PROCEDURE dbo.<Stored Proc Name>
AS
BEGIN
select ''Not Implemented''
END
'
GO
ALTER PROCEDURE dbo.<Stored Proc Name>
AS
BEGIN
--Stored Procedure Code
End
这非常好,因为我不会丢失我的存储过程权限。