您如何在源代码控制中跟踪数据库更改？答案

【问题标题】：How do you track database changes in source control?您如何在源代码控制中跟踪数据库更改？
【发布时间】：2010-09-26 01:13:31
【问题描述】：

我们在大多数项目中使用 SQL Server 2000/2005 和 Vault 或 SVN。我还没有找到合适的解决方案来捕获任一源代码控制系统中的数据库架构/过程更改。

我们当前的解决方案非常繁琐且难以实施（脚本出您更改的对象并将其提交到数据库）。

我们有很多关于如何通过一些自定义开发来解决这个问题的想法，但我宁愿安装一个现有的工具（付费工具也可以）。

那么：您如何跟踪数据库代码更改？你有什么推荐的工具吗？

编辑：

感谢所有建议。由于时间限制，我不想在这里自己动手。而且大多数建议都存在要求开发人员遵循某些程序的缺陷。

相反，理想的解决方案是监视 SQL 数据库的更改并将任何检测到的更改提交到 SCM。例如，如果 SQL Server 有一个附加组件可以记录任何 DML 更改以及进行更改的用户，然后将该对象的脚本提交给 SCM，我会很高兴。

我们在内部讨论了两个系统： 1. 在 SQL 2005 中，使用对象权限来限制您在执行“签出”之前更改对象。然后，签入程序会将其写入 SCM。 2. 运行计划作业以检测任何更改并将它们（匿名）提交到 SCM。

如果我可以跳过用户操作部分并让系统自动处理这一切，那就太好了。

【问题讨论】：

关于这个主题的编码恐怖：blog.codinghorror.com/get-your-database-under-version-control

标签： sql-server svn version-control sourcegear-vault

【解决方案1】：

使用 Visual Studio 数据库版本编写数据库脚本。像一个魅力一样工作，你可以使用任何源代码控制系统，当然如果它有 VS 插件是最好的。该工具还具有许多其他有用的功能。在这篇精彩的博文中查看它们

http://www.vitalygorn.com/blog/post/2008/01/Handling-Database-easily-with-Visual-Studio-2008.aspx

或查看 MSDN 获取官方文档

【讨论】：

【解决方案2】：

可以使用各种第三方工具直接从 SSMS 跟踪数据库更改。 ApexSQL Source Control 自动为版本控制中包含的任何数据库对象编写脚本。该工具无法自动执行提交。相反，用户需要选择提交哪些更改。

从存储库获取更改时，ApexSQL 源代码控制会意识到 SQL 数据库引用完整性。因此，它将创建一个同步脚本，包括将包装在事务中的所有依赖对象，因此，如果没有遇到错误，将应用所有更改，或者不应用任何选定的更改。在任何情况下，数据库的完整性都不会受到影响。

【讨论】：

【解决方案3】：

我不得不说，我认为 Visual Studio 数据库项目也是解决源代码控制困境的合理解决方案。如果设置正确，您可以从 IDE 对数据库运行脚本。如果您的脚本是旧的，请获取最新的，针对数据库运行它。如果您需要，也有一个重新创建所有对象的脚本，新对象也必须手动添加到此脚本中，但只能添加一次

我喜欢每个表、过程和函数都在它自己的文件中。

【讨论】：

+1，谢谢！ TT 在这个答案上打败了你，所以我接受了。

【解决方案4】：

一个穷人的解决方案是添加一个预提交挂钩脚本，该脚本将最新的数据库模式转储到一个文件中，并将该文件与您的代码一起提交到您的 SVN 存储库。然后，您可以从任何修订版中区分 db 模式文件。

【讨论】：

【解决方案5】：

我只是在完整的 SQL-CreateDB-statement 之外提交 SQL-alter-Statement。

【讨论】：

【解决方案6】：

从头开始滚动你自己的不是很可行，但如果你使用像 Redgate SQL Compare SDK 这样的 sql 比较工具来为你生成你的更改文件，半滚动你想要的内容不会花费很长时间，然后只需检查这些文件进入源代码管理。我为自己推出了类似的东西，以便在几个小时内将我们的开发系统的更改更新到我们的实时系统。

【讨论】：

【解决方案7】：

在我们的环境中，我们从不手动更改数据库：所有更改都是在发布时由脚本完成的，并且脚本保存在版本控制系统中。此过程的一个重要部分是确保所有脚本都可以针对同一个数据库再次运行，这些脚本是幂等的？）而不会丢失数据。例如，如果您添加一列，如果该列已经存在，请确保您什么也不做。

您关于“建议存在要求开发人员遵循某些程序的缺陷”的评论确实是一个故事。这不是一个缺陷，这是一个特点。版本控制帮助开发人员遵循程序并使程序不那么痛苦。如果您不想遵循程序，则不需要版本控制。

【讨论】：

【解决方案8】：

在 SQL2000 中将每个对象生成到它自己的文件中，然后将它们全部检查到您的源代码管理中。让您的源代码控制处理更改历史记录。

在 SQL 2005 中，您需要编写一些代码来将所有对象生成到单独的文件中。

【讨论】：

这个答案没有错，但您可以考虑量化手动生成文件所花费的小时数，并得出总成本来帮助证明购买工具来自动化该过程是合理的。 :)

【解决方案9】：

在一个项目中，我在设计中仔细安排了数据库中的所有重要数据都可以从外部位置自动重新创建。在启动时，如果缺少数据库，应用程序会创建数据库，并使用应用程序源代码中的模式（并因此与应用程序一起进行版本控制）从外部数据源填充它。数据库存储名称（一个 sqlite 文件名，尽管大多数数据库管理器允许多个数据库）包括一个模式版本，每当我们提交模式更改时，我们都会增加模式版本。这意味着当我们将应用程序重新启动到具有不同模式的新版本时，会自动创建和填充新的数据库存储。如果我们必须将部署恢复到旧模式，那么旧版本的新运行将使用旧数据库存储，因此我们可以在出现问题时快速降级。

本质上，数据库就像一个传统的应用程序堆，具有持久性、事务安全性、静态类型（因为我们使用 Python 很方便）和唯一性约束等优点。但是，我们完全不担心删除数据库并重新开始，而且人们知道如果他们尝试对数据库进行一些手动 hack，那么它将在下一次部署时恢复，就像对进程状态的 hack 会恢复一样下次重启时。

我们不需要任何迁移脚本，因为我们只是切换数据库文件名并重新启动应用程序，然后它会自行重建。它有助于将应用程序实例分片以每个客户端使用一个数据库。它还减少了对数据库备份的需求。

如果您从外部源构建数据库的时间超过了您允许应用程序保持关闭的时间，则此方法将不起作用。

【讨论】：

这在您拥有一个充满数据的大型数据库并且您必须更改架构之前有效。

【解决方案10】：

如果您正在使用 .Net 并且喜欢 Rails 采用的迁移方法，那么我会推荐 Migrator.Net。

我找到了一个 nice tutorial，它在 Visual Studio 中进行了设置。他还提供了一个示例项目以供参考。

【讨论】：

【解决方案11】：

我们开发了一个自定义工具来更新我们的数据库。数据库模式存储在与数据库无关的 XML 文件中，然后由该工具读取和处理。模式存储在 SVN 中，我们添加适当的注释以显示更改的内容。它对我们很有效。

虽然这种解决方案对于大多数项目来说绝对是矫枉过正，但它确实有时会让生活变得更轻松。

【讨论】：

【解决方案12】：

我们的 dbas 会定期根据 SVN 中的内容检查 prod 并删除任何不受源代码控制的对象。开发人员只需要一次就永远不会忘记再次将某些内容放入源代码管理中。

我们也不允许任何人在没有脚本的情况下将对象移动到 prod，因为我们的开发人员没有 prod 权限，这很容易强制执行。

【讨论】：

【解决方案13】：

为了跟踪所有的变化，比如插入更新和删除，SVN 会有很多开销。最好只跟踪更改架构的 ddl 更改，例如 (alter, drop, create)。您可以通过创建一个表和一个将数据插入该表的触发器来轻松地进行此模式跟踪。您可以随时通过从该表中查询来获取更改状态有很多例子here和here

【讨论】：