如何跟踪源代码管理中的数据库更改？
我们在大多数项目中使用SQL Server 2000/2005和Vault或SVN。我还没有找到一个体面的解决方案来捕获任何源代码管理系统中的数据库模式/程序变更。如何跟踪源代码管理中的数据库更改？
我们当前的解决方案非常繁琐且难以实施（脚本化您更改的对象并将其提交给数据库）。
我们有很多关于如何解决这个问题的一些自定义开发的想法，但我宁愿安装一个现有的工具（付费工具很好）。
所以：你如何跟踪你的数据库代码的变化？你有推荐的工具吗？
编辑：
感谢所有的建议。由于时间限制，我不想在这里推出自己的产品。而且大多数建议都有缺陷，他们需要开发者遵循一些程序。
相反，理想的解决方案是监视SQL数据库的更改并将任何检测到的更改提交给SCM。例如，如果SQL Server有一个附件可以记录任何与做出更改的用户的DML更改，然后将该对象的脚本提交给SCM，我会很高兴。
我们在内部讨论了两个系统： 1.在SQL 2005中，使用对象权限限制您在更改对象之后才执行“结帐”操作。然后，签入过程将它编入SCM。 2.运行预定作业以检测所有更改并将它们（匿名）提交给SCM。
如果我可以跳过用户操作部分并让系统自动处理所有这些，那就太好了。
使用Visual Studio数据库版本编写数据库脚本。像魅力一样工作，您可以使用任何Source控制系统，当然最好是VS插件。该工具还有其他一些有用的功能。检查出来这里在这个伟大的博客文章
http://www.vitalygorn.com/blog/post/2008/01/Handling-Database-easily-with-Visual-Studio-2008.aspx
或退房MSDN的官方文档
一个穷人的解决方案是添加一个预先提交的钩子脚本，将最新的数据库模式转储到一个文件中，并将该文件与您的代码一起提交给您的SVN存储库。然后，您可以从任何修订中区分数据库模式文件。
我只是将SQL-alter-Statement附加到完整的SQL-CreateDB语句中。
在SQL2000 生成每个对象到它自己的文件，然后检查他们都到你的源代码控制。让您的源代码控制处理更改历史记录。
在SQL 2005中，您需要编写一些代码来将所有对象生成为单独的文件。
这个答案没有错，但是你可能会考虑量化手动生成文件所花费的小时数，并拿出一个总成本来帮助证明购买工具来自动完成这个过程。 :) – Mayo 2009-09-18 18:09:13
我不得不说我认为一个视觉工作室数据库项目也是一个合理的解决方案来源控制困境。如果设置正确，则可以从IDE运行针对数据库的脚本。如果您的脚本比较旧，请获取最新版本，然后针对数据库运行它。有一个脚本可以重新创建所有的对象，如果你需要的话，新的对象也必须添加到这个脚本以及手动，但只有一次
我喜欢每个表，proc和函数在它自己的文件中。
+1，谢谢！ TT击败了你这个答案，所以我接受了这个答案。 – 2008-12-15 00:46:44
我们的dbas定期检查SVN中的内容并删除任何不在源代码管理下的对象。在开发者再也不会忘记将某些东西放在源代码控制之前，它只需要一次。
我们也不允许任何人在没有脚本的情况下将对象移动到产品上，因为我们的开发人员没有产品权限，这很容易实施。
从头开始编写自己的代码并不会很好，但是如果使用像Redgate SQL Compare SDK这样的sql比较工具为您生成更改文件，那么不需要很长时间就可以将所需内容半滚动，然后只检查那些文件放入源代码控制。我为自己推出了一些类似的东西，在几个小时内将我们的开发系统的变化更新到我们的实时系统。
在我们的环境中，我们永远不会手动更改数据库：所有更改都是在发布时通过脚本完成的，脚本保存在版本控制系统中。此过程的一个重要部分是确保所有脚本都可以针对相同的数据库再次运行脚本是幂等的？），而不会丢失数据。例如，如果您添加一列，请确保您在列已经存在的情况下不做任何事情。
对于“建议有缺陷的是，他们需要开发人员遵循某些程序”，这真是一个难以置信的故事。这不是一个缺陷，它是一个功能。版本控制可帮助开发人员遵循程序并使程序更轻松。如果你不想遵循程序，你不需要版本控制。
在一个项目中，我经过设计人员的特别关注，可以自动从外部重新创建数据库中的所有重要数据。在启动时，如果应用程序缺失，应用程序将创建数据库，并使用应用程序源代码中的模式（并因此与应用程序一起版本化）从外部数据源填充数据库。尽管大多数数据库管理器允许多个数据库，但数据库存储名称（sqlite文件名）包含模式版本，并且每当我们提交模式更改时，我们都会增加模式版本。这意味着，当我们将应用程序重新启动到具有不同架构的新版本时，会自动创建并填充新的数据库存储。如果我们必须将部署恢复到旧模式，那么旧版本的新版本将使用旧的数据库存储，所以我们可以在发生故障时快速降级。从本质上讲，数据库就像一个传统的应用程序堆，具有持久性，事务安全性，静态类型（自从我们使用Python以来便于使用）和唯一性约束的优点。但是，我们完全不担心删除数据库并重新开始，而且人们知道如果他们在数据库中尝试一些手动破解，那么它将在下一次部署中恢复，就像进程状态的黑客将被恢复一样在下一次重新启动。
我们不需要任何迁移脚本，因为我们只是切换数据库文件名并重新启动应用程序，并重建它自己。它有助于将应用程序实例分割为每个客户端使用一个数据库。它还减少了对数据库备份的需求。
如果从外部数据库构建数据库比使应用程序停留时间更长，则此方法不起作用。
这可以工作，直到你有一个大型的数据库充满数据，你必须改变模式。 – 2011-09-01 18:35:12
如果您正在使用。Net和Rails在迁移时所采用的方法一样，那么我会推荐Migrator.Net。
我发现了一个nice tutorial，它通过在Visual Studio中设置它。他还提供了一个示例项目供参考。
我们开发了一个定制工具来更新我们的数据库。数据库模式存储在数据库中立的XML文件中，然后由该工具读取并处理。模式存储在SVN中，我们添加适当的注释以显示更改的内容。它适合我们。
虽然这种解决方案对于大多数项目来说肯定是矫枉过正，但它有时会让生活更轻松。
跟踪数据库的任何时间直接从SSMS改变是可能使用各种第三方工具。 ApexSQL Source Control自动脚本包含在版本控制中的任何数据库对象。提交不能由该工具自动执行。相反，用户需要选择将提交哪些更改。
从存储库获取更改时，ApexSQL源代码管理系统知道SQL数据库参照完整性。因此，它将创建一个同步脚本，其中包含将包含在事务中的所有依赖对象，以便在遇到错误时应用所有更改，或者不应用所选更改。无论如何，数据库完整性不受影响。
我也喜欢这种方法。 – 2008-12-19 18:54:20