Sql server 验证数据库更改（版本控制）

我读过很多关于数据库版本控制重要性的帖子。然而，我找不到一个简单的解决方案来检查数据库是否处于应该的状态

例如，我有一个数据库，其中有一个名为“Version”的表（版本号存储在那里）。但开发人员可以在不更改版本号的情况下访问和编辑数据库。例如，如果开发人员更新存储过程而不更新版本，则数据库状态与版本值不同步

如何跟踪这些变化？我不需要跟踪更改的内容，只需要检查数据库表、视图、过程等是否与版本表中保存的数据库版本同步

为什么我需要这个？在进行部署时，我需要检查数据库是否“正确”。此外，不应跟踪所有表或其他数据库对象。是否可以不使用触发器进行检查？是否可以在没有第三方工具的情况下完成？数据库有校验和吗

假设我们使用SQLServer2005

编辑：

我想我应该提供更多关于我们当前环境的信息——我们有一个“基线”，包含创建基本版本所需的所有脚本（包括我们应用程序的数据对象和“元数据”）。但是，此“基本”版本的许多安装都带有一些附加的数据库对象（附加的表、视图、过程等）。当我们在“基本”版本中进行一些更改时，我们还必须更新一些安装（不是全部）——那时我们必须检查“基本”是否处于正确状态

---

谢谢

我正在使用一个基于的简单VBScript文件为所有数据库对象生成拖放/创建脚本。然后我将这些脚本置于版本控制之下

因此，为了检查数据库是否是最新的，或者是否有尚未放入版本控制的更改，我执行以下操作：

• 从版本控制（在我们的例子中是subversion）获取最新版本的drop/create脚本
• 为要检查的数据库执行SqlExtract脚本，覆盖版本控制中的脚本
• 现在我可以向我的subversion客户端（TortoiseSVN）检查哪些文件与版本控制下的版本不匹配
• 现在要么更新数据库，要么将修改后的脚本置于版本控制之下

我们用来控制数据库的版本。创建当前数据库的脚本存储在TFS中（与源代码一起），然后使用DBGhost生成增量脚本以将环境升级到当前版本。DBGhost还可以为任何静态/引用/代码数据创建增量脚本

---

它需要从传统方法的思想转变，但这是一个奇妙的解决方案，我无法推荐足够的。虽然它是一款第三方产品，但它与我们的自动化构建和部署过程完美契合。

第一点：没有“法规”，很难保持秩序。 或者举个例子，开发人员在没有通知的情况下更改任何内容都会给您带来严重的问题

总之，你说“不使用触发器”。 有什么具体原因吗

如果没有-请检查DDL触发器。这样的触发器是检查是否发生了什么事情的最简单方法

---

您甚至可以记录所发生的事情。

希望有人有更好的解决方案，但我使用以下几种方法：

• 拥有一个“主干”数据库，这是当前的开发版本。所有工作都在这里完成，因为它正准备包含在发布中
• 每次发布时：
  • 上一版本的“clean”数据库被复制到新版本，例如“DB_1.0.4_clean”
  • 用于将更改从主干复制到1.0.4_clean-这还允许精确检查包含的内容
  • SQL Compare再次用于查找早期版本和新版本之间的差异（从DB_1.0.4_clean更改为DB_1.0.3_clean），这将创建一个更改脚本“1.0.3到1.0.4.SQL”

我们仍在构建自动化此部分的工具，但目标是有一个表来跟踪数据库的每个版本，以及是否应用了更改脚本。升级工具查找最新条目，然后逐个应用每个升级脚本，最后DB是最新版本

我没有这个问题，但是保护干净的数据库不被其他团队成员修改是微不足道的。此外，由于我使用SQL事后比较来生成更改脚本，因此开发人员无需在执行过程中跟踪它们

• 我们确实这样做了一段时间，这是一个巨大的痛苦。这很容易忘记，同时，正在进行的更改并不一定会成功-因此，使用单独创建的更改脚本创建的完整升级脚本有时会添加一个字段，然后将其删除，全部在一个版本中完成。如果索引发生变化，这显然是相当痛苦的

SQL compare的好处在于它生成的脚本位于事务中——如果失败，它将回滚整个过程。因此，如果以某种方式修改了生产数据库，升级将失败，然后部署团队可以在生产数据库上使用SQL Compare与_CleanDB进行比较，并手动修复更改。我们只需要做一两次（该死的客户）

---

.SQL更改脚本（由SQL Compare生成）存储在我们的版本控制系统（subversion）中。

您必须限制对所有数据库的访问，并且只允许开发人员访问本地数据库（他们开发的数据库）和可以进行集成的开发服务器。最好的情况是，他们只能在本地访问他们的开发区域，并通过自动化构建执行集成任务。您可以使用诸如redgates sql compare之类的工具在数据库上进行差异比较。我建议您将所有更改置于源代码管理之下