我们是否应该为每个开发者单独设置数据库实例？

Question

什么是开发基于数据库的应用程序的最佳方法？我们可以有两种方法。

1. 所有开发人员共用一个数据库。
2. 每个开发者都有自己的数据库。

每种方法各有利弊，哪种更好呢？ 编辑： 多个开发者将更新数据库，并且每个开发者机器上都已安装 SqlExpress 2005。 编辑： 我们大多数人都建议使用共同的数据库。但是，如果其中一个开发人员修改了代码和数据库模式。他尚未提交代码更改，但模式更改已导入到共同的数据库中。这不会破坏其他开发人员的代码吗？

- Amitabh

---

如果你还没有听说过，你可以为每个开发者在数据库中设置所谓的“单元模式”。 - Guru

@Guru：什么是"Unit Schemas"？Google 没有给我很多信息。 - Amitabh

关于你的第二次编辑，Amitabh，我们很少破坏东西。如果它会破坏某些东西，开发人员将暂时分开，直到他们的代码被检查后，然后两者将同时合并。再次强调，这是很少见的情况。 - Marcus Adams

这是相同的Oracle模式（在此处：http://www.oracle.com/technology/obe/2day_dba/schema/schema.htm）。在主用户登录中，您可以创建用户并在其中创建相同的对象，并将它们用于开发。 - Guru

我们大多数人都建议使用一个共同的数据库。但是，如果其中一位开发人员修改了代码和数据库架构，他尚未提交代码更改，但架构更改已经进入了共同的数据库，这不可能会破坏其他开发人员的代码吗？这是一个加分项，你想在开发阶段就找出你是否正在破坏其他东西。 - HLGEM

Answer 1

两者皆可 -

我喜欢在上线或进入“正式”测试环境之前对更改进行测试的单个数据库。这是开发人员的理智检查; 它与实时系统保持同步，并确保他们始终考虑彼此的更改。规则应该是，如果更改可能会破坏其他内容，则不会在此处执行更改。

当有多个开发人员进行更新时，每个开发人员都拥有自己的数据库是很好的（甚至必要的）选择。它允许他们获得所有想要的开发灵活性，而不会破坏其他开发人员的工作。

关键是建立一个从开发到实时系统的数据库更改流程，并遵循此流程。

- philiphobgen

---

我发现“中央”数据库也很适用于针对大量数据（例如性能测试等）或生产数据进行测试（数据可能不是您预期的100％）。但正如你所说，这应该在开发人员确认其代码在本地数据库上不会出错之后才会发生。 - Tom H

"...并坚持你的流程"。如果您想为每个开发人员提供自己的数据库（在我看来是一个好主意），这是至关重要的。如果您开始做“只有这一次”的例外，灾难必然会发生。 - DaveE

Answer 2

共享数据库

• 更加简单
• 减少了“在我的电脑上可以运行”的情况。
• 强制整合
• 问题会很快被发现 (快速失败)

个人数据库

• 不会影响其他开发者，但这也是一个坏事，在持续集成方面

我们使用共享的开发数据库，并且效果很好。我们的架构很少更改以一种使其与旧版本不兼容的方式，但有时会在上线之前出现设计变更，然后我们只需要求其他开发人员进行更新即可。

我们确实有单独的开发应用程序（Web）服务器，但它们共享同一个数据库。我们的开发人员确实有使用自己的数据库的选项，因为他们知道如何设置这个，而且偶尔会这样做，但仅是暂时的。对我们来说，通常情况下是共享数据库。

- Marcus Adams

---

我同意Marcus的观点...个人数据库还允许单一位置进行源代码控制集成。我们只在特殊情况下使用个人数据库。最典型的情况是极长的项目开发周期（我们通常每3个月发布一次代码 - 如果一个项目将跨越多个版本，则考虑单独的开发数据库，然后在靠近QA的发布日期之前将代码合并回主要的开发数据库，以防止干扰其他项目）。 - John Franklin

我认为在可以使用共享数据库的情况下更好。通常，在初始设置阶段之后，数据库更改足够缓慢，这样做就可以了。 - Brian MacKay

我尊重地不同意。规范取决于项目类型和规模，也取决于开发方法论。例如，如果您选择共享数据库方法，则无法经常更改架构。如果您不经常更改架构，这很好 :)但是，正如您所说，对于某些任务，您使用单独的数据库，因此可能公平地更改答案以说明对于这样和那样的任务，您使用单独的数据库，而对于这样和那样的任务，您使用共享数据库（如果您的架构不经常更改，那么看起来您的开发工作主要是维护）。 - Unreason

@Unreason，当我说“规范”时，我指的是我们的团队和我们的应用程序。我更新了我的答案以澄清这一点。我们的数据库工作几乎不仅仅是维护。模式经常发生变化，但我们大多数情况下都是添加而不是重构。 - Marcus Adams

好的，那么请在我的参数中将“change”替换为“refactor” :) 我的观点是，您拥有一个共享数据库，但对于某些任务，您使用本地数据库。那么，不能说您将共享数据库用于集成的官方测试（并提供开发，以确保开发不会破坏事物），而当开发需要被隔离时，开发人员会使用本地副本吗？ （即使决策可能由单个开发人员或某些开发人员组自行决定）。这同样重要吗？ - Unreason

Answer 3

我觉得每个开发人员都可以在自己的桌面上托管SQL Server Developer实例，然后为其他环境（开发、QA和生产）设置共享服务器。我认为即使是Visual Studio Pro附带的基本MSDN（如果您选择了它），也包括SQL Server Developer许可证。

开发人员可以在他们的桌面上工作，而不会影响其他人，然后您可以根据需要将代码移动到下一个共享环境中（随意、每日/每周构建等）。

编辑：我应该补充说，桌面实例允许开发人员执行DBA通常在共享环境中限制的操作。这包括数据库创建、备份/还原、分析器等。这些东西并非必需，但它们可以让开发人员更加高效，同时减少他们对DBA的要求。

共享环境对于测试来说是完全必要的 - 我不建议从桌面到生产。但是，通过允许开发人员对给定的数据库环境拥有100%的控制权（包括与其他人隔离），您可以增加很多功能，成本相对较低。

- Mayo

Answer 4

根据您的开发、测试和维护周期，以及开发团队的规模和地点（当然还有组织机构），情况会有所不同。如果您支持多个数据库版本，则可能需要更多环境。

在实际应用中，我发现以下方法比较令人满意：

单一中央数据库/应用程序用于测试目的，定期将各个开发人员的更改合并到其中；

本地副本用于开发（因此您可以自由地删除和重新加载整个数据库）；

升级脚本对架构、辅助和样本数据集的任何更改进行维护。

以下是一些进一步的要点：

如果两个开发人员（两个团队）正在进行可能相互影响的更改，则应独立完成任务，然后进行集成/合并和测试。为此，最好拥有单独的开发环境（除非他们必须一起工作，在这种情况下，我认为他们是同一个团队的一部分；即使如此，他们也可以在自己的数据库副本上工作并在必要时共享它）。

如果他们在不影响彼此的更改上工作，则可以在主服务器上工作。或者在他们自己的数据库本地副本上。

因此，在一般情况下，在本地副本上开发具有所有优点，并且没有风险（当您支持多个系统版本并始终保持升级脚本时）。

如果您能共享测试用例，那么能够轻松快速地转储/恢复数据库的能力是一个巨大的优势。

编辑：
以上所有内容都假设在可行的情况下，在本地机器上拥有整个系统的副本以进行测试（大小、性能、许可证等）。

- Unreason

---

“..获取各个开发人员定期合并到其中的所有更改” - 这是如何完成的？在以前的工作中，我们不得不为每个更改编写手动的SQL脚本来更新模式/数据，并在提交时手动在服务器上运行它。有没有更好、更标准的方法？ - BlueRaja - Danny Pflughoeft

我们有一个XML文件，用于生成创建数据库的脚本和一些通用代码和样例数据集。但是数据库升级脚本需要手动编辑，因为升级的模式更改通常需要以非平凡的方式操作现有数据。在开发过程中，所有正在处理的特定问题都会在源中清楚地标记，并且进行了合并和测试，包括系统的新安装和版本之间的升级。 - Unreason

@BlueRaja，Ruby on Rails 有一种相当优雅的方式来进行数据库升级。其他平台可能也有类似的系统。请参阅http://guides.rubyonrails.org/migrations.html。 - Juha Syrjälä

Answer 5

我会选择解决方案＃1：所有开发人员共用一个数据库。

优点

1. 基础设施费用较少；
2. 刷新开发数据库时只需要一个dump；
3. 每个人都使用相同的数据进行开发，因此它紧密地代表生产环境；

缺点

1. 如果一个开发人员执行错误操作，则可能会影响更多的开发人员。

至于解决方案＃2：每个开发人员拥有独立的数据库；

优点

1. 对于需要隔离开发的新功能开发非常有用；

缺点

1. 对公司而言更加昂贵（基础设施，许可证等）；
2. 急于隔离开发环境所引起的问题的增加（在开发人员的环境中工作，但未集成）；
3. 由DBA进行的来自生产环境的相同副本的dump的增加。

考虑到上述情况，我建议根据您公司的规模而定：

1. 一个用于开发的数据库；
2. 一个用于测试集成的数据库；
3. 一个用于验收测试的数据库；
4. 一个用于新功能开发的数据库，可能需要进行集成测试。

如果您的公司不需要进行集成测试，则应选择验收测试，这一步在进入生产之前非常关键。

- Will Marcouiller

---

+1 这是一个很好的概述，但我有很多评论，并会试图反驳结论。 - Unreason

每个人都使用相同的数据进行开发，因此它更接近生产环境——这可以理解为，在开发时可能需要放弃所有用户数据或其部分数据，或者测试不同的情景。如果保留中央数据库，有时可以派上用场，但也具有一定的限制。 - Unreason

由于急切隔离的开发环境（只在开发者的环境中工作，而不是集成的环境）引起的问题会导致问题的倍增；另一方面，如果人们在同一服务器上开发，他们将在开发过程中互相干扰。我认为这是一个缺点，但你可能会认为早期发现集成问题实际上是好事。但是，我会反驳说这表明最初的更改是有计划的，并且没有建立协调机制。 - Unreason

如果共享数据库需要使用生产数据进行“重置”，那么所有开发人员正在进行的工作都将丢失。 - raupie

Answer 6

每个开发者加上一个持续集成和构建服务器来运行单元测试和集成测试。这样可以让你兼顾两全。

一旦数据库的修改量达到一定级别，让所有开发人员修改同一个开发数据库就会迅速变得不太生产力，因为它会强制开发人员在准备好检入之前部署共享数据库的更改，这意味着代码其他部分可能会不必要地出现故障。

- nvogel

Answer 7

为什么你想要为每个开发者单独设置一个数据库呢？最好为所有人使用一个共同的数据库，这样表结构和SQL语句都是一致的。

- user279521

---

如果你想改变表格结构怎么办？如果你需要测试需要删除所有数据或更改所有数据的内容怎么办？你提出的方法只有在架构被冻结时才能有效，并且即使在这种情况下也不适用于所有任务。如果所有开发人员不在同一个网络上怎么办？这些只是一些可能出现的原因。 :) - Unreason

@Unreason - 我强烈不同意你的观点，我们经常进行模式更改，并且只使用一个数据库。这样，您会更快地发现您的更改是否影响了意外的内容。 - HLGEM

@HLGEM，我表达不够准确 - 我想的是未经协调的模式更改（开发想法，测试某些场景等）; 而你考虑的是协调的更改。我理解你的观点，并认为这个问题有一个很好的答案（stupid-phil）; 最终归结为方法论。 - Unreason

Answer 8

简单的答案：

拥有一个开发数据库，如果开发人员想要自己的，他们可以在自己的机器上运行自己的实例。只需确保在共享数据库上进行测试/发布即可。

- naspinski

---

这需要团队决策，而不是个别开发人员的决定。如果一个开发者在中央数据库上运行检出的代码，则会影响团队中其他人的工作。 - nvogel

Answer 9

我们两者都做：

我们在这里使用代码生成，并且我们的数据库也是由它生成的。因此，每个开发人员的电脑上都有一个实例，用于生成数据库。然后，我们使用生成的脚本将更改应用于中央测试数据库。如果一切顺利，我们会在发布期间将更改应用于生产数据库。

这种方法的好处在于，当我们的“真相之源”被检入源代码控制时，所有数据库更改都会在其他开发人员重新基础和重新生成时自动分发。对我们来说效果很好。

- adam0101

Answer 10

最好的方法是在测试/质量保证服务器上使用单个数据库，每个开发人员都有自己的一个数据库（可能在本地计算机上），这样10个开发人员就可以使用10+1个数据库。

与一般开发相同的方法：每个开发人员在本地计算机上拥有源代码的副本。

此外，多数据库方法简化了将数据库模式保存在版本控制系统中。 我们在SVN中保存数据库创建脚本。

我们使用此方法，如此处所述： http://www.sqlaccessories.com/Howto/Version_Control.aspx

- SQLDev