22

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

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

我们有很多关于如何通过一些定制开发来解决这个问题的想法,但我宁愿安装一个现有的工具(付费工具很好)。

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


编辑:

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

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

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

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

4

13 回答 13

15

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

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

或者查看 MSDN 获取官方文档

于 2008-12-09T14:03:45.010 回答
6

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

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

于 2017-12-07T15:12:35.620 回答
5

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

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

于 2008-12-09T14:19:25.413 回答
3

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

于 2008-12-09T14:01:27.150 回答
1

我只是将 SQL-alter-Statement 附加到完整的 SQL-CreateDB-statement 中。

于 2008-12-09T14:01:34.077 回答
1

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

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

于 2008-12-09T14:04:41.450 回答
1

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

于 2008-12-09T14:34:20.237 回答
1

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

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

于 2008-12-09T16:32:44.083 回答
0

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

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

于 2008-12-09T14:31:33.657 回答
0

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

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

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

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

于 2008-12-15T13:14:43.517 回答
0

如果您正在使用 .Net 并且喜欢 Rails 对 Migrations 采用的方法,那么我会推荐Migrator.Net

我找到了一个很好的教程,介绍了如何在 Visual Studio 中进行设置。他还提供了一个示例项目以供参考。

于 2009-09-18T18:03:25.360 回答
0

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

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

于 2009-09-18T18:15:04.923 回答
0

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

于 2012-06-26T15:02:31.847 回答