管理两个开发人员的sql更改脚本的最佳方法是什么?

时间:2009-09-04 17:08:34

标签: sql sql-server svn scripting

到目前为止,我一直是我客户项目中的孤狼。任何时候我都会对SQL Server进行更改:表更新,存储过程等。我会生成更改脚本并将其放入目录中。当应用程序准备好发布时,我会在实时服务器上运行脚本并完成。

很快我将有另一位开发人员在同一个项目上工作。项目文件都在源代码管理中。我只是不确定如何处理更改脚本。我猜它们也应该受源代码控制?如果是这样,最好的命名约定是什么?我究竟如何确定下一个版本要执行哪些脚本?请记住,这是一个相当低调,非正式的Web项目,没有任何版本号或项目管理软件。

感谢。

8 个答案:

答案 0 :(得分:5)

是的,你应该把它们放在源代码管理中。命名约定与其一致无关紧要。一种方法是在每个脚本的文件名中附加一个人工(创建一个)应用程序版本号。如果您提供更多详细信息,我们可能会为您提供更好的命名示例。但是,你肯定希望它们在源代码控制中。

答案 1 :(得分:2)

我们将更改脚本控制为.sql文件,然后将sql文件的执行顺序保存在批处理文件中,该文件也受源代码管理。批处理文件使用sql文件作为参数调用OSQL:

SQLScripts.Bat:

SET BASEDIR=%%1
SET SERVER=%%2
SET DATABASE=%%3

CALL RUNISQLW CreateUserPresets %BASEDIR% %SERVER% %DATABASE%
CALL RUNISQLW CreateFundWorkflows %BASEDIR% %SERVER% %DATABASE%
CALL RUNISQLW spFundWorkflowAddFromTemplate %BASEDIR% %SERVER% %DATABASE%
CALL RUNISQLW spFundWorkflowListForGrid %BASEDIR% %SERVER% %DATABASE%
CALL RUNISQLW spWorkflowTasksListForGrid %BASEDIR% %SERVER% %DATABASE%
CALL RUNISQLW fGetToleranceDate %BASEDIR% %SERVER% %DATABASE%
CALL RUNISQLW fGetNotifyDate %BASEDIR% %SERVER% %DATABASE%
CALL RUNISQLW spWorkflowTasksManager %BASEDIR% %SERVER% %DATABASE%
CALL RUNISQLW spWorkflowTasksAnalyst %BASEDIR% %SERVER% %DATABASE%
CALL RUNISQLW spWorkflowTasksNotify %BASEDIR% %SERVER% %DATABASE%
CALL RUNISQLW AddGateFrequency %BASEDIR% %SERVER% %DATABASE%

pause

RUNISQLW:

@REM First Parameter: Name of SQL file, without the .SQL extension.
@REM Second Parameter: Base Directory to run the file in.
@REM Third Parameter: Name of the server to run the file on.
@REM Fourth Parameter: Name of the Database on the server.

osql -S %3 -d %4 -E  -i %2\%1.sql -o %2\Output\%1.txt

然后,我们从deployment.bat文件中为每个配置environemt,Dev,Staging或Production调用SqlScripts批处理文件。这使得它在配置中保持一致。

答案 2 :(得分:1)

我建议解决的一个重要组成部分是订购 - 文件应包括(可能在开始时)某种可排序的日期&时间戳。这样,您就可以准确地测试和调试执行脚本的 order

答案 3 :(得分:1)

我目前将我的sql更改脚本存储在一个文件夹中并命名它们,脚本订单号,表名,更改说明

  

1-用户创建-table.sql

     

2-User-added-columns.sql

     

...

     

名词

当我执行这些脚本时,我将它们移动到一个名为“release 2009-09-01”的新文件夹中,然后继续下一个数字

答案 4 :(得分:0)

如果您使用的是VS Team Edition,则可以使用数据库版本为正在使用的sql server版本创建数据库项目。

然后,从数据库构建项目,以便将所有函数,视图和表格都放入项目中。

然后,无论何时进行更改,都可以在项目中进行更改,因此可以轻松地在svn中(每个文件都在那里)然后您可以同步您的sql server数据库。

通过这种方式,您可以更新您的队友所做的更改,而不会弄乱您的数据。

答案 5 :(得分:0)

另一种方法是使用像http://www.red-gate.com/products/SQL_Compare/index.htm

这样的工具

它为单个部署生成更改脚本。好消息是你不必再依赖开发人员的纪律了。

除此之外,我仍然希望在SVN中安装数据库。我使用SQLScript,请参阅free utility to script DB objects in ms sql

修改

我现在使用Redgate SQL Version。使用它很容易将更改放入SVN。唯一的问题是我必须启动并使用应用程序,而不是自动化过程。

答案 6 :(得分:0)

开始学习如何在源代码控制中使用分支。在协同工作时,这可能非常有价值。

一些分支策略可以是:

  • 在开发人员之后命名分支(然后项目中的每个开发人员将负责使他们的分支与主线保持同步)。
  • 为每个功能创建一个新分支,然后在合并之后删除分支(仅对分布式版本控制系统真正可行)

答案 7 :(得分:0)

查看DBSourceTools中使用的修补引擎 它专门用于帮助开发人员在源代码控制下获得SQL服务器数据库。

此工具允许您在特定点建立数据库基线,并创建命名版本(v1) 然后,创建部署目标 - 并将命名版本增加到v2 将补丁脚本添加到Patches目录,以获取对架构或数据的任何更改 最后,检查数据库和所有补丁到源代码控制,与devs分发。

这给您带来了一个可重复的过程来测试从v1到v2应用的所有补丁 DBSourceTools还具有帮助您创建这些脚本的功能,即模式比较或脚本数据工具。

完成后,补丁目录中的所有文件都将成为您的版本,并将您的数据库从v1升级到v2。

玩得开心。