我正在努力跟上数据库的变化，以及如何干净地维护和部署从Dev到PRD的数据库更改，从一个版本到另一个版本。
目前，我使用SQL脚本来确定自上次发布以来发生的变化;
但我认为我无法理解的主要问题是我们在任何两个主要的PRD版本之间都有Dev和UAT的多个迷你版本。
Dev和UAT mini发布是可以的，因为我得到了其他开发人员的更改列表，我将它与我的相结合，然后做了一个发布，加上我是开发人员和UAT数据库的系统管理员所以我确切知道什么是的，当我应用更改时会发生什么。
对于PRD，我必须准备一个干净的脚本并将其交给DBA，这样他就可以在那里运行它，但除了PRD上的表名，列和数据之外，我无法查看任何其他内容。
并且PRD的这个脚本应该捕获几乎所有进入迷你版本的内容，但大多数时候这些迷你版本不是顺序的，有时会相互否定，因为在一个添加功能A然后后续版本删除功能A但对于PRD，我们可能需要添加功能A，因此无需进行第二次迷你发布，这将有效删除功能A.
因此，简而言之，我正在研究如何管理和跟踪版本之间的数据库更改，以及为数据库更改构建部署脚本的好方法。
注意：我确实手动维护了TFS中所有SQL对象的副本。
我尝试使用数据库项目，但我没有得到很多运气实现我想要的东西。
任何想法的家伙？任何帮助非常感谢
答案 0 :(得分：2)
我不熟悉TFS，我之前使用过Git（CVS和SVN），因此我们就这个答案了。
管理和版本化SQL位是我做梦中最糟糕的事情。 有一些工具可以轻松实现更改管理，红门SQL Developer Bundle，它可以处理比较，并允许连接到版本控制系统。在您的请求中，您可以使用idera SQL比较工具集，不应过度查看idera的完美主义方法。
无论如何，在我看来，管理变更不能也不应该被视为技术性的事情，它必须是IT治理的一部分，而且程序性，它需要在任何相关功能之间进行记录和通信。
当发生一些小型发布，热修复，微更改或类似的事情时，它们必须反映在需要获取它的每个其他环境中。
当然，如果在制作中有迷你版本并且你是UAT的中间版，你可能不想在该环境中插入迷你版本。 IMO，在UAT之后不久，您应该将迷你版本应用于环境并执行E2E QA会话，以确保环境良好。
如果您阅读我之前的段落，您可能会发现一些问题，让我们说UAT有SP版本4而迷你版本相同SP就是2 ...你怎么确定你没有造成回归吗
这是版本控制系统和合并工具的帮助。 Red Gate工具还应该可以帮助您构建部署。
但是，我认为治理，沟通和遵守规则是持续成功的最重要因素。
今天的趋势是实施持续集成，按需构建测试环境，内部，托管和云端。通常他们建造和维护并不便宜，但他们还清了！
最后但并非最不重要的是，在开发SQL部署时应遵守的几条规则：
答案 1 :(得分：1)
我知道我迟到了，但请尝试使用 redgate 工具，它是控制数据库对象的来源和同步的最佳工具。我一直在使用这个工具，并且对结果深信不疑。有许多选项可以将您的 SQL 脚本、用户、安全性、设置和特殊数据从一个数据库同步到另一个数据库。