每个开发人员一个DB或不？

Question

在主要编写管理软件的企业开发环境中，每个开发人员是应该使用自己的数据库实例，还是应该在开发期间使用中央数据库实例？每种方法的优点和缺点是什么？那么其他环境和其他产品呢？

Answer 1

如果您共享同一个数据库，那么如果有人对数据库进行结构更改并且代码未与其“同步”，则可能会出现一些问题。

我强烈建议每个开发人员使用一个数据库，这是因为您不想进行“写入”测试以查看其他人立即覆盖您的唯一原因。一个简单的例子？您尝试显示网站的产品。一切正常，直到所有产品消失。问题？另一位开发人员决定使用该产品的“Active”标志来测试其他内容。在这种情况下，交易可能甚至不起作用。故事的结尾，你花时间调试别人的行动。

我强烈建议偶尔将临时数据库复制到开发人员数据库以同步结构（或者更好，有一个从头开始重建数据库的工具）。

当然，我们需要脚本来更改数据库，而所有内容都在源代码管理中。

Answer 2

数据库环境应该稀缺的日子早已不复存在。我正在XW9300上写这篇帖子，里面有5x15k的SCSI磁盘。这台机器将在相当合理的时间内运行大量的ETL工作，并且（在2007年中期）在ebay上花费了大约1,700英镑，包括磁盘。从开发人员的角度来看，尤其是数据仓库等数据库中心项目，开发人员和DBA之间的界限非常模糊。在我写这篇文章的过程中，我正在为SQL Server 2005数据仓库构建一个分区管理框架。

开发人员应该拥有一个或多个自己的开发数据库（IMO）这些原因：

• 要求人们在源代码管理中保留存储过程，补丁脚本和架构定义文件。应用补丁可以在很大程度上自动化。甚至还有Redgate SQL Compare Pro这样的工具为此做了大量的工作。

• 鼓励应用程序架构简化配置管理和部署，因为人们必须部署到自己的工作站上。许多部署皱纹在生产之前很久就会被整理出来，或者人们甚至意识到它们可能出错了。

• 避免开发人员绊倒彼此的工作。在人们使用ETL代码的数据仓库这样的事情上，这是一个更大的胜利。

• 它鼓励一定程度的责任，因为开发人员必须学习基本的数据库管理。这也消除了对运营支持人员和一些开发人员的大量要求。 ops friction。

• 如果您拥有自己的数据库，则没有看门人阻碍实验或其他工作。由于没有“服务器”，围绕管理“服务器”的政治消失了。 在具有显着现任官僚作风的任何环境中，这都是一种生产力的胜利。

• 对于小数据量，普通PC足够快。大多数（如果不是所有）数据库管理系统都可以使用开发人员版本或许可，并且可以在桌面操作系统上运行。如果你正在使用Linux或Unix，这就不是问题了。对于更大的数据量，包括大多数MIS应用程序，像HP XW9400或Lenovo D10这样的工作站可以配备5个15k磁盘，其成本低于大量professional { {3}} development。 （是的，我知道它是双重许可证，但QT的商业全平台许可证大约为4000英镑）。 像这样的机器将运行一个ETL过程，比你想象的要快10到100百万行。

• 它有助于为烟雾测试或对帐目的设置多个环境。由于您可以完全控制机器，因此您可以在生产环境中模拟条件。例如，我曾经为tooling创建了一个简单的模拟器，只需要避开一些运行时脚本。 如果您对环境具有这种级别的控制和透明度，那么您可以生成一个相当强大的测试部署流程，这样做可以消除生产部署中指责的机会。

我见过小团队在14个环境中工作，同时在工作站上有7个活动。在ETL这样的数据库繁重的工作中，你在整个表中工作，在单一的开发环境中工作是浪费时间或花时间在蛋壳上行走的方法。

此外，您可以将单用户开发许可证用于数据库平台，这样可以节省数据库许可中工作站的成本。大多数开发人员许可证（Microsoft和OTN是我熟悉的几个示例）将允许您在单个工作站上为单个开发人员免费或以名义价格使用该系统。

相反，共享开发服务器上的许可条款通常有些模糊，我看到供应商不止一次试图让客户拒绝在开发服务器上获得许可。

Answer 3

我们的每个开发人员都拥有功能齐全的数据库。与任何其他代码一样，更改是脚本化和源代码控制的。

Answer 4

理想情况下，是的，每个开发人员都应该有一个“沙盒”开发环境，因此他们甚至可以在将代码部署到共享测试/暂存环境之前对其进行测试。

每个开发人员的环境都应该运行脚本化测试，将数据库重置为已知状态。这在共享环境中是不可能的。

为每个开发人员提供他们自己的实例的成本低于多个开发人员试图在共享环境中一起测试volatile变化所导致的混乱成本。

另一方面，在许多IT商店中，系统使用复杂的基础设施，涉及多个应用服务器或多个物理节点。然后是经济学的变化;人们合作并避免踩到彼此的工作比为每个开发人员复制它更便宜。特别是如果您集成了昂贵的第三方系统，而这些系统没有为多个开发环境提供许可证。

所以答案是肯定的，不是。 :-)如果可以低成本地再现该环境，请给每个开发人员提供他们自己的环境。

Answer 5

我的建议是拥有2个级别的开发环境：

每个开发人员都有自己的个人开发系统，有自己的dp，Web服务器等。这允许他们针对已知的设置进行编码，编写自动（系统级）测试，将他们的数据库和系统初始化为已知状态，等

开发集成环境由所有开发人员共享，用于确保一切按预期方式一起工作，然后再交给QA。代码从源代码控制中检出并安装在那里，并且只有一个服务器实例（db或其他）。

Answer 6

这个问题暗示了开发人员需要做他/她的工作。当然应该提供私有数据库实例。同样重要的是，我会确保数据库与您要部署的产品/版本相同。不要在MySQL 6.x上开发并部署到MySQL 5.x. （这适用于app服务器和Web服务器！）

拥有开发人员数据库并不一定需要在本地计算机上托管。您可以拥有一个中央DBMS主机，其上包含所有dev dbs。专业人员是您针对目标数据库开发的garauntee。开发盒的开销更少，更强大的IDE和应用服务器的空间/马力更大。缺点是所有开发者的单点故障。 （DBMS服务器停止运行，没有人可以工作。）缺乏设置和管理DBMS的开发。开发人员无法轻松地通过即将发布的数据库版本或备用数据库选择来解决棘手问题。

根据您的组织和结构，一些专业人员可能会受到影响，反之亦然。也许你不希望devs管理DBMS。也许您计划支持不同的数据库平台。决定归结为您的组织以及您的目标平台选择。如果您计划针对各种DB / OS / app服务器组合，那么每个开发人员不仅应该拥有自己的数据库，而且应该以独特的组合工作。 （MySQL / Tomcat / OSX用于一个DB2 / Jetty / Linux用于另一个Postegres / Geronimo / WinXP用于第三个等）如果您在iSeries上设置ASP（应用程序服务提供商）类型的商店，那么当然你可能有一个包含所有dev dbmses的中央主机，每个dev至少应该有一个单独的数据库实例，以允许对模式进行结构更改。

Answer 7

我公司的部门只有有限的开发环境，纯粹是因为支持和硬件成本。我们有几个基于t-1夜间刷新生产的环境，以及一些静态环境。

理想情况下，每个人都应该拥有自己的，但在许多情况下，如果以下情况属实，这将是不切实际的：

• 你有大量的开发人员需要资源（我们的部门可能有80个）
• 每个开发人员需要多个资源（通常我每天使用4-5个不同的dbs）
• 最新数据非常重要（你只是不能快速刷新它们）

在这些情况下，需要共享实例和良好的沟通。

Answer 8

我在本地安装了SQLServer Development Edition实例。我们有一个QA DB服务器，以及多个生产服务器。所有开发和集成测试都是使用我的本地服务器（或其他开发人员本地服务器）完成的。新版本将发布到QA服务器。每个版本在客户接受后投入生产。

由于我主要进行Web开发，因此我使用与VS2008捆绑在一起的Web服务器进行开发和本地测试，然后将Web应用程序发布到VM上托管的QA Web服务器。一旦被客户接受，它就会被发布到几个不同的生产Web服务器之一 - 一些是虚拟的，一些不是，取决于应用程序。

Answer 9

数据库模式应该保存在源代码管理中，开发人员应该拥有一起检查代码和数据库的变更集。在签入之前，开发人员应该在他自己的数据库上工作。签入后，自动构建（例如：登记，夜间等）应该更新中央集成数据库以及应用程序本身。

在开发人员实例级别，加载的数据至少应适合于单元测试。在集成级别，共享数据库应该保存适合于测试的数据，但不应该依赖于生产复制 - 这只是托管测试数据的松散替代。

根据我的经验，开发人员选择共享数据库的唯一原因是他们认为开发和运行最近的生产数据在某种程度上是“真实的”，这意味着他们可以减少测试工作量。他们喜欢踩在彼此的脚趾上，并忍受一个共享数据库，在下一次生产刷新之前慢慢腐蚀，而不是编写和管理正确的测试。正是这种管理实践为IT世界提供了目前所拥有的不良声誉。

Answer 10

每个开发人员一个数据库。没有问题。但问题实际上是如何编写整个数据库的脚本，“控制数据”，并对它们进行版本控制。我的解决方案在这里：http://dbsourcetools.codeplex.com/ 玩得开心。 - 内森。

Answer 11

我喜欢妥协解决方案（所有开发人员共享基础架构，如果有人需要测试架构更改，他们会创建自己的临时数据库实例（也许有一个只是为了这个目的坐在那里？），直到他们乐意提交新的模式来源控制。）

Answer 12

我曾在两种类型的开发环境中工作过。就个人而言，我更喜欢拥有自己的DB / app服务器。但是，使用共享基础架构进行开发可能会有一些优势。

主要的一点是共享环境更接近真实场景：当所有开发人员共享数据库时，您更有可能发现锁定或事务的问题。给每个开发人员自己的数据库可能会导致“它适用于我的数据库”综合症。

但是，如果您需要应用和测试架构更改或优化，那么我可以在这种设置中看到问题。

也许妥协的解决方案最有效：所有开发人员共享基础架构，如果有人需要测试架构更改，他们会创建自己的临时数据库实例（也许有人只是为了这个目的而坐在那里？）直到他们乐意将新架构提交给源代码控制。

您在源代码管理中确实拥有整个架构（和测试数据），对吗？右???

Answer 13

在我的公司，我们倾向于在处理非平凡的新功能时复制整个数据库。有磁盘空间的原因是便宜的，而意外的数据丢失（即使它是测试数据）也不是。

Answer 14

我们的每个开发人员都有一个本地数据库。我们在SVN仓库中存储创建脚本和“标准数据”的转储。我们有一组广泛的测试必须通过这个测试数据。我们还有一个“沙盒”数据库，可供人们将数据放入他们想要共享的标准数据中。这对我们很有用，并允许我们让开发人员修改他们的本地数据副本来测试，但我们控制传递给其他开发人员的内容。我们还严格控制架构更改，因此我们不会遇到其他人提到的问题。

Answer 15

我认为这里有一个术语问题。我已经有一段时间了，因为我戴着我的DBA帽子（大约10年） - 所以别人可以插话并纠正我。

我认为每个人都同意每个开发人员都应该拥有自己的沙盒架构。

在MySQL和Sybase / MS SQLServer中，每个数据库引擎都可以支持多个数据库。每个数据库（通常）完全独立于其他数据库。因此，您可以拥有一个数据库引擎实例，并为每个开发人员提供他想要的数据库空间。唯一的问题是如果开发人员使用tempdb - 那里可能会发生冲突（我认为 - 你需要查找）。请注意，不要使用具有固定数据库名称的跨数据库查询。

在Oracle中，数据库引擎实例与特定模式集绑定。如果同一引擎上有多个开发人员，则他们都指向同一个表。在这种情况下，是的，您需要运行多个实例。

Answer 16

我喜欢在开发人员必须被隔离时使用本地版本的想法 - 开发模式更改，性能测试，设置特定方案等...

在其他时候使用共享版本以确保所有内容彼此同步。

Answer 17

这实际上取决于您的应用程序的性质。如果您的是分布式环境中的客户端 - 服务器体系结构，则最好使用每个人都使用的中央数据库。如果产品为用户提供了具有本地数据库实例的环境，则可以使用该实例。最好是您的开发尽可能地反映现实世界环境。

它还取决于您所处的开发阶段。可能在早期阶段，您不希望因连接，网络和分布式环境问题而陷入困境，只是想要启动并运行。在这种情况下，您可以在切换到中央模型之前从每个用户的数据库实例模型开始，因为产品达到了某种程度的成熟度。

Answer 18

每个开发人员对一个数据库有一个好处，每个开发人员都有一个处于“已知”状态的自己数据的快照。

Answer 19

我建议使用数据库的一个实例。您不希望数据库成为移动目标。