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

Question

的背景

我的小组有4个SQL Server数据库:

• 生产
• UAT
• 测试
• 开发

我在Dev环境中工作.当需要推广我一直在处理的对象(表格,视图,函数,存储过程)时,我向我的经理提出请求,他提升了测试.在测试之后,她向促进UAT的管理员提交请求.用户测试成功后,同一个Admin会升级到Production.

问题

由于一些原因,整个过程很尴尬.

1. 每个人都必须手动跟踪他们的更改.如果我更新,添加,删除我需要跟踪它们的任何对象,以便我的促销请求包含我所做的一切.从理论上讲,如果我错过了一些测试或UAT应该抓住它,但这不确定,无论如何都浪费了测试人员的时间.
2. 我做的很多更改都是​​迭代的,并在GUI中完成,这意味着没有记录我所做的更改,只有最终结果(至少据我所知).
3. 我们正处于建立数据集市的相当早期阶段,因此大多数变更(至少是计数方面)都是次要的:改变列的数据类型,在我们明确的时候改变表的名称它们将被用于,调整函数和存储过程等.

问题

人们几十年来一直在做这种工作,所以我想有必要有一个更好的方法来管理这个过程.我想要的是,如果我可以在两个数据库之间运行差异以查看结构是如何不同的,使用该差异生成更改脚本,使用该更改脚本作为我的促销请求.这可能吗？如果没有,有没有其他方法来组织这个过程？

为了记录,我们是100%的微软商店,刚刚将所有内容更新到SQL Server 2008,因此该软件包中可用的任何工具都是合理的游戏.

---

我应该澄清一下,我不一定要寻找差异工具.如果这是同步我们环境的最佳方式,那么它很好,但如果有更好的方法我正在寻找它.

做我想要的事情的一个例子是Ruby on Rails中的迁移.死的简单语法,所有更改都会自动记录,默认情况下,确定需要运行的迁移几乎非常简单.如果SQL Server有类似的东西,我会很高兴.

我理想的解决方案是1)容易和2)很难搞砸.Rails迁移都是; 到目前为止,我在SQL Server上所做的一切都不是.

Answer 1

版本控制和您的数据库

一切邪恶的根源在于用户界面的改变。SSMS 是一种 DBA 工具，而不是开发人员工具。开发人员必须使用脚本对数据库模型/架构进行任何类型的更改。对元数据进行版本控制并将脚本从每个版本 N 升级到版本 N+1 是被证明可靠工作的唯一方法。它是 SQL Server 本身部署的用于跟踪元数据更改（资源数据库更改）的解决方案。

SQL Compare 或vsdbcmd等比较工具以及 VS 数据库项目中的 .dbschema 文件只是无法采用正确版本化方法的商店的最后手段。它们在简单的场景中工作，但我发现它们在严重的部署中都失败了。如果工具试图复制数据，人们只是不相信该工具会对 +5TB 表进行更改......