21

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

  1. 一个供所有开发人员使用的通用数据库。
  2. 为所有开发人员提供单独的数据库。

各自的优缺点是什么？哪一个是更好的方法？

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

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

4

12 回答 12

18

两个都 -

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

当多个开发人员进行更新时，每个开发人员的数据库非常好（甚至是必不可少的）。它允许他们在不破坏其他开发人员的情况下获得他们想要的所有开发灵活性。

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

于 2010-05-21T12:59:01.873 回答
10

共享数据库

  • 更简单
  • “它适用于我的机器”的案例较少。
  • 力量整合
  • 快速发现问题（快速失败）

个人数据库

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

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

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

于 2010-05-21T12:59:43.880 回答
8

Thought I'd throw this out there, but why not let every developer host their own instance of SQL Server Developer on their desktops and then have a shared server for each of the other environments (development, QA, and prod)? I think even the basic MSDN that comes with Visual Studio Pro (if you opt for it) includes a license for SQL Server Developer.

The developer can work on their desktop without impacting the others and then you can have them move the code to the next shared environment as you see fit (at will, with daily/weekly builds, etc.).

EDIT: I should add that the desktop instance allows developers to do things that he DBAs often restrict on shared environments. This includes database creation, backup/restore, profiler, etc.. These things are not essential but they allow the developer to become so much more productive while reducing the demands they make against your DBAs.

The shared environment is completely necessary for testing - I would not recommend going from desktop to production. But you can add so much by allowing the developers to have 100% control over a given database environment (including isolation from others) with a relatively minor cost.

于 2010-05-21T13:15:17.277 回答
2

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

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

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

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

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

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

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

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

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

于 2010-05-21T13:33:37.467 回答
1

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

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

于 2010-05-21T14:56:29.757 回答
1

你到底为什么要为所有开发人员提供一个单独的数据库？所有人都有一个通用数据库，这样表结构一致，sql语句也一致。

于 2010-05-21T13:00:40.463 回答
1

我们两者都做：

我们在我所在的地方使用代码生成，并且我们的数据库也被生成。因此，我们在每个开发人员的盒子上都有一个生成数据库的实例。然后我们使用生成的脚本将更改应用到中央测试数据库。如果一切顺利，我们将在发布期间将更改应用到生产数据库。

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

于 2010-05-21T13:33:39.320 回答
1

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

优点

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

缺点

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

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

优点

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

缺点

  1. 对公司来说更贵（基础设施、许可证……）；
  2. 急切隔离开发环境导致的问题成倍增加（在开发者的环境中工作，未集成）；
  3. 来自生产环境的相同副本的 DBA 转储倍增。

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

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

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

于 2010-05-21T13:09:36.370 回答
0

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

  • 首先，它不太可能是真正的生产数据库的大小（如果你把我们需要在这里使用的所有数据库都拿出来，它们会占用几百 GB 的空间，我的机器上没有可用的空间），这个导致编写错误的代码，由于性能原因，这些代码永远不会在大型数据库上运行。绝不应该针对比 prod 上的数据集小得多的数据集编写 SQL 代码。
  • 其次，使用自己的数据库的开发人员在花费很长时间开发某些东西时会产生问题，然后只有在与真实数据库合并后才发现它会影响其他东西。当您共享环境时，您会更快地找到这些东西。所以最终会减少浪费的开发时间。
  • 第三个从事相关工作的开发人员需要了解您所做的更改，这将影响他们的更改。

当你知道你会影响他人时，我认为你会更加小心你所做的事情，这在我的书中是一个加号。

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

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

于 2010-07-13T14:38:52.450 回答
0

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

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

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

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

于 2010-05-21T13:54:33.907 回答
0

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

于 2010-05-21T17:12:48.793 回答
0

简单的回答：

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

于 2010-05-21T13:21:08.447 回答