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

Question

背景

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

• Production
• UAT
• Testing
• Developer

我在开发环境中工作。当需要提升我一直在处理的对象（表，视图，函数，存储的过程）的时候，我向经理提出了要求，经理将其提升为Test。经过测试后，她向提升为UAT的管理员提交了请求。在成功进行用户测试之后，同一管理员将晋升为正式生产。

问题

出于某些原因，整个过程很尴尬。

1. 每个人都必须手动跟踪他们的更改。如果我进行更新，添加，删除需要跟踪它们的所有对象，以便我的升级请求包含我已完成的所有工作。从理论上讲，如果我错过了某些测试或UAT应该抓住它，但这并不确定，并且无论如何都浪费了测试者的时间。
2. 我所做的很多更改都是​​在GUI上迭代完成的，这意味着没有记录我所做的更改，只有最终结果（至少据我所知）。
3. 我们正处于构建数据集市的初期阶段，因此所做的大部分更改（至少在数量方面）都是次要的事情：更改列的数据类型，在具体化表内容时更改表的名称它们将用于调整函数和存储的过程等。

问题

人们从事这种工作已有几十年了，所以我认为必须有一种更好的方法来管理该过程。我想要的是，如果我可以在两个数据库之间运行差异以查看结构差异，使用该差异生成更改脚本，然后将该更改脚本作为我的升级请求。这可能吗？如果没有，还有其他方法可以组织此过程吗？

作为记录，我们是一家100％的Microsoft商店，刚刚将所有内容更新到SQL Server 2008，因此该软件包中提供的任何工具都是公平的游戏。

---

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

Ruby on
Rails中的移植是我真正想要做的一个很好的例子。语法简陋，自动记录了所有更改，默认情况下，确定要运行的迁移几乎是轻而易举的。我很想知道SQL
Server是否有与此类似的东西。

我理想的解决方案是1）简单，2）搞砸。Rails迁移都是两者；到目前为止，我在SQL Server上所做的一切都不是。

Answer 1

版本控制和您的数据库

万恶的根源在于在UI中进行更改。SSMS是一种DBA工具，而不是开发人员工具。开发人员必须使用 脚本
对数据库模型/架构进行各种更改。对元数据进行版本控制以及从每个版本N升级到版本N + 1的升级脚本是经证明可可靠运行的 唯一 方法。这是SQL
Server本身部署的解决方案，用于跟踪元数据更改（资源数据库更改）。

VS Database项目中的SQL Compare或vsdbcmd和.dbschema文件之类的比较工具只是无法采用正确版本控制方法的商店的最后手段。它们在简单的场景中工作，但我看到它们在严重的部署中都会严重失败。如果工具试图
复制 数据，则只是不信任该工具可对+ 5TB表进行更改…