我们应该为每个开发人员分别设置数据库实例

Question

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

1. 所有开发人员的一个通用数据库。
2. 为所有开发人员分开数据库。

每种的优点和缺点是什么？哪一个更好的方式？

编辑：不止一个开发人员应该更新数据库，我们已经在每个开发人员计算机上安装了SqlExpress 2005。

编辑：我们大多数人都在建议使用通用数据库。但是，如果其中一个开发人员修改了代码和数据库架构。他没有提交代码更改，但架构更改已转到公共数据库。它是否会破坏其他开发人员的代码。

Answer 1

两者 -

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

当多个开发人员进行更新时，每个开发人员的数据库都很棒（甚至是必不可少的）。它允许他们所需的所有开发灵活性，而不会为其他开发人员破坏。

关键是要有一个流程，用于将数据库更改从开发转移到您的实时系统，并坚持您的流程。

Answer 2

共享数据库

• 简单
• 较少的情况“它适用于我的机器”。
• 强制整合
• 快速找到问题（快速失败）

个人数据库

• 永远不会影响其他开发人员，但这在持续集成中也是一件坏事

我们使用共享开发数据库，​​它运行良好。我们的架构很少以一种使其向后兼容的方式发生变化，但偶尔会在我们上线之前进行设计更改，我们只是要求其他开发人员更新。

我们有单独的开发应用程序（Web）服务器，但它们共享同一个数据库。我们的开发人员可以选择使用他们自己的数据库，因为他们知道如何设置它，并且有时会这样做，但只是暂时的。对我们来说，标准是共享数据库。

Answer 3

以为我会把它扔到那里，但为什么不让每个开发人员在他们的桌面上托管他们自己的SQL Server Developer实例，然后为每个其他环境（开发，QA和prod）提供共享服务器？我认为即使Visual Studio Pro附带的基本MSDN（如果你选择它）也包括SQL Server Developer的许可证。

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

修改 我应该补充一点，桌面实例允许开发人员执行DBA经常限制共享环境的事情。这包括数据库创建，备份/恢复，分析器等。这些事情并不重要，但它们可以让开发人员提高效率，同时减少他们对DBA的要求。

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

Answer 4

取决于您的开发，测试和维护周期。还有关于开发团队（当然还有组织）的规模和位置。如果您支持多个版本的数据库，则可能需要更多环境。

在现实世界中，我发现以下方法令人满意：

• 用于测试目的的单个中央数据库/应用程序，由各个开发人员定期合并到其中的所有更改
• 用于开发的本地副本（因此您可以自由删除并重新加载整个数据库）
• 为架构，辅助和示例数据集的任何更改维护升级脚本

以下是其他一些观点：

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

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

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

如果您可以共享测试用例，那么仍然很好，因此能够轻松快速地转储/恢复数据库是一个很大的优势。

编辑：
以上所有都假设在整个系统的本地机器上有一个副本用于测试目的是可行的（大小，性能，许可证等）。

Answer 5

为什么您希望为所有开发人员提供单独的数据库？ 拥有一个共同的数据库，这样表结构是一致的，sql语句也是如此。

Answer 6

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

<强>赞成

1. 基础设施成本较低;
2. 在刷新开发数据库时只需要一次转储;
3. 每个人都使用相同的数据进行开发，因此它代表了生产环境;

<强>缺点

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

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

<强>赞成

1. 当开发需要隔离时，这可能对新功能开发有用;

<强>缺点

1. 公司更贵（基础设施，许可证......）;
2. 由急切的隔离开发环境引起的问题的倍增（在devloper的环境中工作，未集成）;
3. 来自生产环境的同一副本的DBA转储。

考虑到上述情况，我建议，视公司规模而定：

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

如果您的公司不需要集成测试，那么请进行验收测试，此步骤在投入生产之前至关重要。

Answer 7

我们同时做到了：

我们使用代码生成，我也在生成数据库。因此，我们在每个开发人员的框中都有一个实例，用于生成数据库。然后，我们使用生成的脚本将更改应用于中央测试数据库。如果情况良好，我们会在发布期间将更改应用于生产数据库。

这种方法的好处在于，当我们的“事实来源”签入源代码控制时，所有数据库更改在重新生成和重新生成时会自动分发给其他开发人员。它对我们很有用。

Answer 8

简单回答：

有一个开发数据库，​​如果开发人员想要自己的开发数据库，​​他们可以在自己的机器上运行自己的实例。请务必在共享上进行测试/发布。

Answer 9

最好的方法是每个开发人员在Test / QA服务器上的单个数据库和一个数据库（可能在开发人员的本地计算机上）（因此，10个开发人员使用10 + 1个数据库）。

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

此外，多数据库方法简化了版本控制系统中保留数据库架构的过程。我们在SVN中保留数据库创建脚本。

我们正在使用此处描述的方法： http://www.sqlaccessories.com/Howto/Version_Control.aspx

Answer 10

每个开发人员加一个持续集成和构建服务器来运行单元和集成测试。这给了你两全其美。

一旦数据库更改量达到一定水平，让所有开发人员快速修改单个开发人员数据库的效率就会降低，因为它迫使开发人员在准备签入之前将更改部署到共享数据库，这意味着其他部分代码行可能会不必要地破坏。

Answer 11

您可能还想查看Refactoring Databases。除了讨论数据库变更之外，他还讨论了从开发到生产的各种方式，以降低风险。

Answer 12

开发人员拥有自己的数据库的最大问题是：

• 首先它的大小不太可能 真实的生产数据库（如果 你拿走了我们需要的所有数据库 在这里工作，他们会接受 几百GB的空间，我 没有我的 机器），这会导致错误的代码 写的，永远不会工作的 大型数据库的性能 原因。永远不应该针对比prod上的数据集小得多的数据集编写SQL代码。
• 第二，开发者使用自己的 数据库创建问题时 花了很长时间开发 什么，然后才发现 在他们与真正的数据库合并之后 它会影响别的东西。您 当你发现这个东西的速度要快得多 分享环境。所以有 最终减少了浪费的发展 时间。
• 第三个从事相关工作的开发人员 事情需要知道变化 你正在制作，它会影响他们 变化。

当你知道自己会影响他人时，我认为你会更加小心你所做的事情，而不是我的书。

现在，共享数据库服务器应该具有我们称之为临时数据库的地方，人们可以在这里创建和测试表更改，因此如果他们正在做一些可能需要删除并重新创建表的内容（这应该是一种罕见的情况） ！），他们可以首先通过将表复制到临时数据库并在那里运行他们的进程来测试该进程，然后在他们确定它工作时切换到真实数据库。或者我们经常在测试特定更改之前将备份表复制到临时数据库，因此如果旧数据变坏，我们可以轻松地重新创建旧数据。

我认为使用单个数据库没有任何优势。