SQL Server数据库更改工作流程的最佳做法

我的组有4个SQL Server数据库：

>生产
> UAT
>测试
>开发

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

问题

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

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

问题

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

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

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

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

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

解决方法

所有邪恶的根源都是在UI中进行更改. SSMS是一个DBA工具,而不是开发人员.开发人员必须使用脚本对数据库模型/模式进行任何类型的更改.对元数据进行版本控制并将升级脚本从每个版本N升级到版本N 1是唯一可靠的方法.它是SQL Server自身部署的解决方案,用于跟踪元数据更改(资源数据库更改).

来自VS数据库项目的SQL Compare或vsdbcmd和.dbschema文件等比较工具只是未能采用正确版本化方法的商店的最后一个度假村.它们在简单的场景中工作,但我看到它们在严肃的部署中都失败了.如果工具试图复制数据,那么只是不相信一个工具来更改5TB表…

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!