2010-07-24 69 views
9

团队在数据库上工作有什么更好?它是每个开发人员或共享数据库的本地数据库实例吗?使用数据库的最佳实践团队

+0

它取决于如何设计数据库模式(如果设计的话),测试数据的复杂程度,数据库模式的稳定程度以及内容。随着发展的进行可能会有所不同。 – pascal 2010-07-24 09:23:34

+0

什么是BD?这是一个数据库的错字,还是我没有听说过的产品? – 2010-07-24 09:30:35

+0

我发现这篇文章: http://odetocode.com/blogs/scott/archive/2008/01/30/three-rules-for-database-work.aspx 但我同意“pascal”它取决于数据库大小,模式和其他特征。 – k0stya 2010-07-24 09:40:07

回答

12

根据我的经验,团队应该有(至少)一个用于整合的共享数据库。

在开发过程中,每个团队成员应该有一个独立的数据库,否则数据库模式的变化可能会阻碍其他团队成员。这些实例也可能位于中央服务器上。

1

根据经验,共享数据库更好。我们的代码常常被打破,因为有人在本地数据库中添加了一列,然后将他们的新源代码上传到SVN。然后其他人的实现将会中断,直到他们发现数据库中发生了什么变化。

我会有一个共享的数据库进行开发。我们还有一个或两个开发数据库也用于其他测试。

+0

在另一种情况下,如果某人更改了数据库中的列类型并且没有上传ORM模式? – k0stya 2010-07-24 09:55:11

+1

我们以相同的方式处理应用程序代码和DB代码(存储过程,模式更改)。我们确实有偶尔忘记的数据库更新,但开发人员很快就知道,当我们确定有问题的代码时,他们宁愿不要在他们面前发现鸡蛋,因为持续集成和测试并不难。我们有一条规则,您需要在签入和编写针对数据库的自动化测试之前编写升级脚本。 – aqwert 2010-07-25 23:12:20

4

我只能谈的方式,团队我目前的工作是,这符合我们的需求不够好:

我们有一个自动更新任何数据库的最新架构的版本一个中央数据模型脚本。开发人员检查对该脚本的更改以及对源代码的更改(同一存储库上的单一提交)。每晚构建更新一个中央数据库副本,随后对该数据库进行一批自动化测试,而人类QA团队第二天也会使用同一个数据库进行所有测试。

除了通过集成构建之外,我们不允许以任何其他方式对中央数据库实例进行架构更改。为了开发模式更改脚本,可以在中央服务器上或在本地(取决于个人偏好)在单独的数据库实例上开发更改。

4

我不认为它完全取决于。每个环境应该有它自己的数据库实例。就个人而言,我绝不会推荐团队中的每个人都在同一个源代码副本上工作,并且我以同样的方式查看数据库代码和实例。

如果您在更改数据库时发生问题,这是不同开发过程问题的症状。忘记将代码文件添加到源代码管理将会非常不方便。

Jeff Atwood has a pretty good article on source controlling database code.

不同的开发者在不同的问题理应工作 - 你如何避免踩到别人的脚趾,而单元测试?

我绝对主张通过Continuous Integration process进行更新的集成/测试环境。这个环境也经常作为您部署过程的试金石。

3

在Redgate,我们建议每个开发者都有自己的实例,因为沙盒确保开发者不会踩在彼此的脚趾上。但是,这两种模式都有优点和缺点。

根据我们与数据库开发人员交流的经验,大约有一半的数据库开发是在共享环境中执行的,一半是在专用的每个开发人员环境中执行的。

1

为开发人员提供独立的数据库实例可以帮助他们隔离工作,但是如果我们是一个庞大的团队并在同一时间处理多件事情,那么最好还是共享一个环境,以便所有需要的更改在同一时间交付并没有打破对方,他们的依赖也可以正确计算出来。这也有助于确定任何应用程序可能由于更改而中断的地方。所以最好有一个共享的环境以及开发环境的一些单独的环境副本,以防万一我们想要测试一些非常重要且需要工作的大而复杂的东西。

但唯一的问题是保持多个环境相互同步,因为任何遗漏的变化都可能是致命的。

+0

是的,拥有独立的数据库*和*“集成”测试的共享环境显然是理想的选择,如果您仔细考虑,这就是持续集成提供的。开发人员应该在单独的沙箱上进行开发,将其更改提交到源代码管理,这会触发持续集成,从而构建和测试包含所有更改的数据库。 – 2011-09-17 09:06:02

1

我知道这里的人是根据他们过去的经历来讲的,但这并不是一个普遍回答的简单问题。每种方法都有优点和缺点,应根据您正在使用的应用程序和团队的类型加以解决。

如果您不知道要走哪条路..我建议先与共享的开发数据库一起查看是否遇到任何问题。如果此解决方案有效,它应该是首选方法,因为它消除了“集成”步骤。但是,根据团队类型和环境需求,您可能需要适应。