SQL Server数据库更改工作流最佳实践

Version Control and your Database

万恶之源在于用户界面的改变。SSMS是DBA工具,而不是开发人员工具。开发人员必须使用 脚本 对数据库模型/模式进行任何类型的更改。对元数据进行版本控制,并使升级脚本从每个版本N升级到版本N+1是最重要的 这种方式被证明工作可靠。它是SQLServer自己部署的用于跟踪元数据更改(资源数据库更改)的解决方案。

比较工具,如SQL Compare或 vsdbcmd 复制 数据。。。

在我们的团队中,我们处理数据库更改的方式如下:

• 我们(重新)生成一个 脚本 完整的数据库 并将其与其他更改一起签入版本控制。我们有4个文件:表、用户定义的函数和视图、存储过程和权限。这是完全自动化的-只需双击即可生成脚本。
• 如果开发人员必须对数据库进行更改,她会对自己的数据库进行更改 本地数据库
• 对于每一个变化,我们创造 更新脚本
• 这个 已测试更新脚本
• 更新脚本遵循 命名约定 所以每个人都知道按什么顺序执行。

这对我们来说相当有效,但是如果几个开发人员大量修改相同的表和视图,仍然需要一些协调。但这种情况并不经常发生。

重点是:

• 由脚本修改 ,但本地开发商的数据库除外。这很重要。
• SQL脚本有版本控制 通过源代码控制-db可以像过去任何时候一样创建
• 已创建 有规律地
• 对数据库的更改可以很快完成,因为这些更改的脚本创建起来相对容易。

但是,如果您的项目有很多持久的开发分支,那么这可能不会很好地工作。

到目前为止,这还不是一个完美的解决方案,需要采取一些特别的预防措施。例如,根据数据库中存在的数据,如果存在可能失败的更新,则应在生产数据库的副本上测试更新。

RedGate销售 SQL Compare ,一个生成更改脚本的优秀工具。

VisualStudio也有支持数据库比较的版本。这以前叫做 Database Edition

在我工作的地方,我们很早以前就废除了Dev/Test/UAT/Prod分离,转而使用 very quick release cycle

SQL Compare . 棒极了,强烈推荐。SQL Compare将允许您在两个数据库之间的模式中进行差异,甚至可以为您构建SQL更改脚本。

另一个(如果您是visualstudio商店)是visualstudio的架构和数据比较特性(不确定是哪个版本)。

同意SQL Compare是一个惊人的工具。

但是,我们不会像其他代码一样对数据库结构或未在源代码管理中编写和保存的对象进行任何更改。然后,您就可以确切地知道您正在升级的版本中属于什么,因为您拥有该特定版本的脚本。

无论如何,通过GUI进行结构更改是个坏主意。如果您有大量数据,那么至少在SQLServer中,它比使用ALTERTABLE慢得多。您只需要使用经过测试的脚本来对prod进行更改。

我同意marapet的评论,每一个改变都必须有脚本。
但是,您可能遇到的问题是创建、测试和跟踪这些脚本。

http://dbsourcetools.codeplex.com

它是专门为帮助开发人员在源代码控制下获取SQLServer数据库而设计的。

然后,创建一个部署目标-并将命名版本增加到v2。
将修补程序脚本添加到修补程序目录中,以便对架构或数据进行任何更改。
最后,将数据库和所有补丁检查到源代码控制中,与devs一起分发。

玩得高兴。

另一个用于数据库的“Diff”工具:

http://www.xsqlsoftware.com/Product/Sql_Data_Compare.aspx

1. 在版本控制表中保留数据库版本
2. 保留已成功应用的脚本文件名
3. 保留已应用的每个sql脚本的md5总和。在计算md5 sum时应该忽略空格。必须有效。
4. Keep info关于谁应用了脚本Keep info关于何时应用了脚本
6. 应自动应用新的sql脚本
7. 如果已应用的脚本的md5 sum发生更改,则应抛出错误(在生产模式下)
8. 脚本发布后,不能更改。一定是的 在生产环境中是不可变的。
9. 脚本应该以某种方式编写,这样它就可以应用于不同类型的数据库(参见liquibase)
10. 由于大多数数据库上的大多数ddl语句都是自动提交的,所以最好每个SQL脚本都有一个ddl语句。
11. ddlsql语句应该以某种方式运行,这样就可以执行多次而不会出错。在开发模式下,当您可以多次编辑脚本时,确实很有帮助。例如,仅当新表不存在时才创建新表,甚至在创建新表之前删除表。它将帮助您在开发模式下使用尚未发布的脚本,更改它,清除此脚本的md5 sum,然后重新运行它。
12. 每个sql脚本都应该在自己的事务中运行。
13. 更新。
14. Sql脚本保存在svn这样的版本控制系统中
16. 即使脚本失败,也不会给您带来太大的麻烦 解决它

这是我们成功使用的工作流:

• 转移到生产环境:我们使用microsoftvisualstudio中的sqlschema比较dev和proddb之间的模式。我们使用相同的工具更新prod。