你们是否在您选择的源代码控制系统中跟踪存储过程和数据库模式?
当您进行更改时(添加表、更新存储过程,如何将更改导入源代码管理?
我们在工作中使用 SQL Server,并且我已经开始使用 darcs 进行版本控制,但我对一般策略以及任何方便的工具感到好奇。
编辑:哇,伙计们,感谢所有很棒的建议!我希望我可以选择多个“接受的答案”!
最佳答案
我们选择编写所有内容的脚本,包括所有存储过程和架构更改。不需要所见即所得的工具,也不需要花哨的“同步”程序。
架构更改很容易,您只需为该版本创建和维护一个文件,包括所有架构和数据更改。这将成为您从版本 x 到 x+1 的转换脚本。然后,您可以针对生产备份运行它,并将其集成到您的“每日构建”中,以验证它是否正常工作。请注意,重要的是不要更改或删除已经编写的架构/数据加载 sql,因为您最终可能会破坏以后编写的任何 sql。
-- change #1234
ALTER TABLE asdf ADD COLUMN MyNewID INT
GO
-- change #5678
ALTER TABLE asdf DROP COLUMN SomeOtherID
GO
对于存储过程,我们为每个存储过程选择一个文件,它使用删除/创建形式。所有存储过程都在部署时重新创建。缺点是如果更改是在源代码控制之外进行的,则更改将丢失。同时,这对任何代码都是正确的,但您的 DBA'a 需要意识到这一点。这确实阻止了团队外的人破坏您的存储过程,因为他们的更改在升级中丢失了。
使用 Sql Server,语法如下所示:
if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[usp_MyProc]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)
drop procedure [usp_MyProc]
GO
CREATE PROCEDURE [usp_MyProc]
(
@UserID INT
)
AS
SET NOCOUNT ON
-- stored procedure logic.
SET NOCOUNT OFF
GO
唯一剩下要做的就是编写一个实用程序来整理所有单独的文件并创建一个包含整个更新集的新文件(作为单个脚本)。为此,首先添加模式更改,然后递归目录结构并包括所有存储过程文件。
作为对所有内容编写脚本的一个好处,您将在阅读和编写 SQL 方面变得更好。你也可以把整个过程做得更精细,但这是在没有任何特殊软件的情况下如何对所有 sql 进行源代码控制的基本格式。
附录:Rick 是正确的,您将失去对具有 DROP/CREATE 的存储过程的权限,因此您可能需要编写另一个脚本来重新启用特定权限。该权限脚本将是最后运行的。我们的经验发现 ALTER 与 DROP/CREATE 语义有更多问题。 YMMV
关于sql-server - 源代码管理中的存储过程/DB 模式,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/77172/