保持sql数据库模式在开发人员之间同步

时间:2009-05-27 16:45:22

标签: .net sql development-environment

我们是一个小型开发团队(约5人)从不同地点开展开发项目。 我们使用SVN作为代码回购 我们现在面临的最大问题是我们的数据库架构在我们所有人之间完全不同步。 我有以下几种选择: 1.解决“中央”数据库问题。这是一个坏主意,很可能不会发生 2.让一个“看门人”开发人员继续使用数据库版本,并让每个开发人员随时了解更改。 3.让每个开发人员将他们的更改检查到数据库更改脚本中。这很快就会变得混乱。

很抱歉只是提到它是.net c#project

有什么想法吗?

9 个答案:

答案 0 :(得分:1)

这是一个难题。我们通过修改用于生成模式的sql(从Enterprise Architect自动生成)来处理它。我们遇到了很大的问题,人们不会更新他们的数据库模式,因为他们认为重新创建一个拥有有效测试数据的数据集需要很长时间。

我们的解决方案是:

  • 将SQL架构生成添加到SVN
  • 将数据插入脚本添加到SVN
  • 将架构/数据转储添加到SVN

我们使用Hudson来设置自动数据库构建,以检查修订中的更改。它会自动重新创建模式,插入所有数据,导出转储文件,然后将转储文件提交给SVN。

基本上,它归结为运行数据库导入大约需要20秒。一旦快速创建数据库,开发人员就不会经常遇到问题。

答案 1 :(得分:1)

为什么再次使用相同的数据库服务器是一个坏主意?因为所有开发人员都在进行可能会伤害他人的变更?如果是这种情况,我会让一个人处理架构更改并使用VPN进入具有数据库服务器的网络。我现在正在同一条船上,只需选择一台思科路由器来处理我需要的便宜(<100美元)。

答案 2 :(得分:1)

几年前我从Paul Graham那里读到了一篇关于“敏捷数据库开发”的文章。我在谷歌搜索时遇到了麻烦。似乎所有这些术语都有点过于通用,而且我的记忆有点过于模糊而无法靠近。

我确实跑过了http://code.google.com/p/migratordotnet/

它以Rails ActiveRecord迁移器(前面提到过)为蓝本,但针对的是.net。我不是.net程序员,但这听起来像你正在寻找的东西。

答案 3 :(得分:1)

我们目前正在进行的项目中遇到了同样的问题。我们采用Tarantino作为解决方案,效果出奇的好。每个开发人员都在使用本地数据库。当开发人员需要进行架构更改时,他/她会创建一个脚本并将其签入。

Tarantino会跟踪每个开发人员已在其本地数据库上运行的脚本并应用新脚本。因此,如果开发人员A进行更改并检入SQL脚本,则开发人员B将在从源代码控制获取lates文件时获得更改。当开发人员B在本地运行Tarantino时,只会应用最新的脚本。

当然,大部分可以手动完成。塔伦蒂诺让它变得更容易,但并不完美。一个优点是它可以非常容易地集成到构建过程中。还可以创建用于维护数据库中数据的脚本。

答案 4 :(得分:1)

MS有点落伍,因为它还没有标准的解决方案,但是你的#3选项(更改脚本)是现在的方法。大多数其他现代主流语言现在使用各种不同风格的形式。例如查看Rails迁移。

This post讨论了一系列第三方.NET解决方案。根据我的经验,migratordotnet是一个很好的选择。有关问题的更详细检查,请查看Martin Fowler关于此主题的article

答案 5 :(得分:0)

您是否考虑过使用Visual Studio Team Database Edition?它允许您将整个源数据库放入源代码控制中,每个开发人员都可以处理自己的更改,然后一旦他们检查它们,其他开发人员就可以轻松地将这些更改部署到他们自己的工作副本中。

不确定是否有适用于MSSCCI提供商的SVN插件 - 但我想应该有一些东西可用于此。

答案 6 :(得分:0)

假设您没有使用Team Edition可视化工作室产品,那么我会选择选项3.也可以在源代码管理下使用sql脚本。

保持本地数据库同步与要求他们使用最新的源代码没有什么不同。

如果您正在使用Team产品,那么请开始使用Database edition(随Developer Edition一起提供)在源代码管理下管理您的数据库

答案 7 :(得分:0)

我也在一个小团队工作,现在我们将SQL模式和数据插入脚本检入存储库,就像我们的代码一样。

您需要确保人们与最新的“来源”保持同步。我们倾向于对我们遇到的任何重大变更/修订进行实践,然后讨论它们,让每个人都了解被修改的内容,并提供在审核之前审查任何数据库更新的机会。

答案 8 :(得分:0)

这个问题不再常见。每个团队都必须在某个时候提出这个问题。我已经完成了常见的数据库方法和单独的数据库方法。团队总是回到公共数据库。它更容易维护,每个人都应该尽早同步,经常同步。这并不否定在版本控制中保持模式更改和定义的必要性。您需要一个可重复的过程来更新测试,登台和生产环境。纯SQL迁移并不总是足够,但有时您需要使用本机对象来生成数据或做出决策。我见过的最好的系统(类似于我自己用perl,php和Java构建的系统,但改进了几点)是Ruby on Rails迁移系统。检查出来并做类似的事情。