在主要编写管理软件的企业开发环境中，每个开发人员应该使用自己的数据库实例，还是应该在开发期间使用中央数据库实例？每种方法的优点和缺点是什么？其他环境和其他产品呢？
Pablo Cabrera
问问题
4412 次
19 回答
36
如果你们都共享同一个数据库，那么如果有人对数据库进行了结构更改并且代码没有与之“同步”，那么您可能会遇到一些问题。
我强烈建议每个开发人员使用一个数据库，唯一的原因是您不想进行“编写”测试以看到其他人在之后立即覆盖您。一个简单的例子？您尝试为网站展示产品。一切正常，直到所有产品消失。问题？另一位开发人员决定使用产品的“活动”标志来测试其他东西。在这种情况下，交易甚至可能不起作用。故事结束，你花时间调试别人的动作。
我强烈建议不时将登台数据库复制到开发人员数据库以同步结构（或者更好的是，拥有一个从头开始重建数据库的工具）。
当然，我们需要脚本来更改数据库，并且一切都在源代码管理中。
于 2008-10-24T17:50:27.133 回答
16
数据库环境应该稀缺的日子已经一去不复返了。我在一个带有 5x15k SCSI 磁盘的XW9300上写这篇文章。这台机器将在相当合理的时间内运行大量的 ETL 工作，并且（在 2007 年年中）我在 ebay 上花了大约 1,700 英镑，包括磁盘。从开发人员的角度来看，尤其是在数据仓库等以数据库为中心的项目中，开发人员和 DBA 之间的界限非常模糊。在我写这篇文章时，我正在为 SQL Server 2005 数据仓库构建一个分区管理框架。
出于（IMO）这些原因，开发人员应该拥有一个或多个自己的开发数据库：
要求人们将存储过程、补丁脚本和模式定义文件保存在源代码控制中。应用补丁可以在很大程度上自动化。甚至还有像Redgate SQL Compare Pro这样的工具可以为此做很多繁重的工作。
鼓励一种便于配置管理和部署的应用程序架构，因为人们必须部署到他们自己的工作站上。许多部署问题在投入生产之前很久就会得到解决，或者人们甚至意识到他们可能出错了。
避免开发人员在彼此的工作中绊倒。在人们使用 ETL 代码的数据仓库之类的东西上，这是一个更大的胜利。
它鼓励一定程度的责任感，因为开发人员必须学习基本的数据库管理。这也消除了对运营支持人员和一些开发人员的许多要求。操作摩擦。
如果您拥有自己的数据库，则没有任何守门人会阻碍实验或其他工作。由于没有“服务器”，围绕管理“服务器”的政治消失了。在任何存在大量官僚机构的环境中，这都是生产力的胜利。
对于小数据量，一台普通的 PC 就足够快了。开发人员版本或许可适用于大多数（如果不是全部）数据库管理系统，并将在桌面操作系统上运行。如果您使用的是 Linux 或 Unix，这将不是什么大问题。对于更大的数据量，包括大多数 MIS 应用程序，像HP XW9400或Lenovo D10这样的工作站可以配备 5 个 15k 磁盘，其成本低于许多专业 开发 工具的成本。（是的，我知道这是双重许可，但 QT 的商业全平台许可大约是 4000 英镑一个席位）。像这样的机器运行 ETL 过程的速度比您想象的要快 10 到 100 百万行。
它有助于为烟雾测试或协调目的设置多个环境。由于您可以完全控制机器，因此在生产环境中模拟条件的空间很大。例如，我曾经为Control-M制作了一个简单的仿真器，只是安装了一些运行时脚本。如果您对环境具有这种级别的控制和透明度，则可以生成经过相当稳健测试的部署过程，这在很大程度上消除了生产部署中相互指责的机会。
我见过小型团队在 14 个环境中工作，同时有 7 个在工作站上活动。在 ETL 等数据库繁重的工作中，您需要处理整个表，在单个开发环境中工作是浪费时间或花时间在蛋壳上行走的秘诀。
此外，您可以为数据库平台使用单用户开发许可证，这可以为您节省仅在数据库许可方面的工作站成本。大多数开发人员许可证（Microsoft 和 OTN 是我熟悉的几个示例）将允许您在单个工作站上免费或以象征性价格为单个开发人员使用该系统。
相反，共享开发服务器上的许可条款通常有些模糊，而且我看到供应商不止一次地试图说服客户在开发服务器上获得许可。
于 2008-10-24T18:13:39.317 回答
7
我们的每个开发人员都有一个功能齐全的数据库。与任何其他代码一样，更改是脚本化和源代码控制的。
于 2008-10-24T17:48:00.057 回答
5
理想情况下，是的，每个开发人员都应该有一个“沙盒”开发环境，因此他们甚至可以在将代码部署到共享测试/暂存环境之前对其进行测试。
每个开发人员的环境都应运行脚本测试，将数据库重置为已知状态。这在共享环境中是不可能做到的。
为每个开发人员提供自己的实例的成本低于多个开发人员试图在共享环境中一起测试易失性更改所导致的混乱成本。
另一方面，在许多 IT 商店中，系统使用复杂的基础架构，涉及多个应用服务器或多个物理节点。然后经济发生变化；与为每个开发人员复制它相比，人们合作并避免踩到彼此的工作成本更低。如果您集成了昂贵的第三方系统，而这些系统没有为您提供多个开发环境的许可证，则尤其如此。
所以答案是肯定的和否定的。:-) 如果可以廉价地复制该环境，请为每个开发人员提供自己的环境。
于 2008-10-25T02:20:08.070 回答
4
我的建议是拥有 2 个级别的开发环境：
每个开发人员都有自己的个人开发系统，有自己的 dp、Web 服务器等。这允许他们针对已知设置进行编码，编写自动化（系统级）测试，将他们的数据库和系统初始化为已知状态等。
开发集成环境由所有开发人员共享，用于确保一切按预期协同工作，然后再将其交给 QA。代码从源代码管理中签出并安装在那里，并且任何服务器（db 或其他）只有一个实例。
于 2008-10-24T17:55:12.177 回答
3
这个问题暗示了开发人员需要做他/她的工作。当然应该提供一个私有数据库实例。同样重要的是，我会确保数据库与您打算部署到的产品/版本相同。不要在 MySQL 6.x 上开发并部署到 MySQL 5.x。（这适用于应用服务器和 Web 服务器！）
拥有开发人员数据库并不一定意味着您需要将其托管在本地计算机上。您可以拥有一个中央 DBMS 主机，其中包含所有开发数据库。专业人士是您针对目标数据库开发的 garauntee。开发盒的开销更少，强大的 IDE 和应用服务器的空间/马力更多。缺点是所有开发人员的单点故障。（DBMS 服务器出现故障，没有人可以工作。） 开发人员缺乏设置和管理 DBMS 的机会。开发人员无法轻易尝试即将发布的数据库版本或替代数据库选项来解决棘手的问题。
根据您的组织和结构，一些优点可能是缺点，反之亦然。也许您不希望开发人员管理 DBMS。也许您确实计划支持不同的数据库平台。该决定归结为您的组织以及您的目标平台选择。如果您计划针对各种 DB/OS/app 服务器组合，那么每个开发人员不仅应该拥有自己的数据库，而且应该以独特的组合工作。（MySQL/Tomcat/OSX 用于一个 DB2/Jetty/Linux 用于另一个 Postegres/Geronimo/WinXP 用于第三个等）如果您在 iSeries 上设置 ASP（应用程序服务提供者）类型商店，那么当然您'可能会有一个包含所有开发 dbmses 的中央主机，但每个开发人员至少应该有一个单独的数据库实例，以允许对架构进行结构更改。
于 2008-10-25T03:17:17.973 回答
1
我在本地安装了一个 SQLServer Development Edition 实例。我们有一个 QA DB 服务器，以及多个生产服务器。所有开发和集成测试都是使用我的本地服务器（或其他开发人员本地服务器）完成的。新版本暂存到 QA 服务器。每次发布，经客户验收后，投入生产。
由于我主要做 Web 开发，所以我使用与 VS2008 捆绑的 Web 服务器进行开发和本地测试，然后将 Web 应用程序发布到托管在 VM 上的 QA Web 服务器。一旦被客户接受，它就会被发布到几个不同的生产网络服务器之一——一些是虚拟的，一些不是，这取决于应用程序。
于 2008-10-25T02:46:35.553 回答
1
我公司的部门只有有限的开发环境，纯粹是因为支持和硬件成本。我们有几个基于生产环境中的 t-1 夜间刷新的环境，以及一些静态环境。
理想情况下，每个人都应该有自己的，但在许多情况下，当满足以下条件时，这将是不切实际的：
- 您有大量需要资源的开发人员（我们部门可能有 80 个）
- 每个开发人员都需要多种资源（通常我每天使用 4-5 个不同的数据库）
- 最新数据很重要（您只是不能足够快地刷新它们）
在这些情况下，需要共享实例和良好的沟通。
于 2008-10-25T06:41:02.927 回答
0
每个开发人员使用一个数据库的一个优势是，每个开发人员都拥有自己处于“已知”状态的数据的快照。
于 2008-10-24T17:53:05.537 回答
0
这实际上取决于您的应用程序的性质。如果您的架构是分布式环境中的客户端-服务器架构，那么最好有一个每个人都使用的中央数据库。如果产品为用户提供了具有本地数据库实例的环境，您可以使用它。如果您的开发尽可能地反映现实世界的环境，那将是最好的。
这也取决于您处于哪个开发阶段。可能在早期阶段，您不想被连接性、网络和分布式环境问题所困扰，只想启动并运行。在这种情况下，您可以从每用户数据库实例模型开始，然后在产品达到一定成熟度时切换到中央模型。
于 2008-10-24T17:55:20.430 回答
0
我喜欢在必须隔离开发人员时使用本地版本的想法——开发架构更改、性能测试、设置特定场景等......
在其他时候使用共享版本以确保一切都彼此同步。
于 2008-10-24T17:56:05.327 回答
0
我认为这里存在术语问题。我已经有一段时间没有戴上我的 DBA 帽子了（天哪，快 10 年了）——所以其他人可以插话并纠正我。
我认为每个人都同意每个开发人员都应该有自己的沙箱模式集。
在 MySQL 和 Sybase/MS SQLServer 中，每个数据库引擎可以支持多个数据库。每个数据库（通常）完全独立于另一个数据库。因此，您可以拥有一个数据库引擎实例，并为每个开发人员提供自己的数据库空间，让他们随心所欲。唯一的问题是如果开发人员正在使用 tempdb——那里可能会发生冲突（我认为——这你需要查找）。请注意不要使用具有固定数据库名称的跨数据库查询。
在 Oracle 中，数据库引擎实例与特定的模式集相关联。如果您在同一个引擎上有多个开发人员，他们都指向同一个表。在这种情况下，是的，您将需要运行多个实例。
于 2008-10-24T17:58:40.393 回答
0
我们的每个开发人员都有一个本地数据库。我们将创建脚本和“标准数据”的转储存储在我们的 SVN 存储库中。我们有一组广泛的测试，必须针对这些测试数据通过。我们还有一个“沙盒”数据库，可供人们将他们想要共享的数据放入标准数据中。这对我们很有效，允许我们让开发人员修改他们的本地数据副本来测试东西，但我们控制传递给其他开发人员的内容。我们也严格控制模式的变化，所以我们不会遇到别人提到的问题。
于 2008-10-24T17:58:44.323 回答
0
在我的公司中，我们在处理重要的新功能时倾向于复制整个数据库。有磁盘空间的原因很便宜，而意外的数据丢失（即使是测试数据）不是。
于 2008-12-11T17:17:51.293 回答
0
我曾在这两种类型的开发环境中工作过。就个人而言，我更喜欢拥有自己的数据库/应用服务器。但是，使用共享基础架构进行开发可能有一些优势。
主要的一点是共享环境更接近于现实世界的场景：当所有开发人员共享一个数据库时，您更有可能发现锁定或事务的问题。为每个开发人员提供自己的数据库可能会导致“它适用于我的数据库”综合症。
但是，如果您需要应用和测试架构更改或优化，那么我可以在这种设置中看到问题。
也许折衷的解决方案效果最好：所有开发人员共享基础设施，如果有人需要测试架构更改，他们会创建自己的临时数据库实例（也许有一个只是为了这个目的而坐在那里？），直到他们乐于提交新的模式到源代码控制。
您确实在源代码控制中拥有整个架构（和测试数据），对吗？对？？？
于 2009-03-03T20:09:51.320 回答
0
我喜欢折衷解决方案（所有开发人员共享基础架构，如果有人需要测试架构更改，他们会创建自己的临时数据库实例（也许有一个只是为了这个目的而坐在那里？），直到他们乐于将新架构提交给源代码控制。）
于 2009-06-15T07:09:16.177 回答
0
每个开发人员一个数据库。没有问题。但问题实际上是如何编写整个数据库的脚本、“控制数据”并对其进行版本控制。我的解决方案在这里：http ://dbsourcetools.codeplex.com/ 玩得开心。- 内森。
于 2009-07-07T13:11:13.980 回答
0
数据库模式应该保存在源代码控制中，开发人员应该拥有为代码和数据库一起签入的变更集。在签入之前，开发人员应该在他自己的数据库上工作。签入后，自动构建（例如：签入时、夜间等）应更新中央集成数据库以及应用程序本身。
在开发人员实例级别，加载的数据至少应该适合单元测试。在集成级别，共享数据库应该保存也适合测试的数据，但不应该依赖生产复制——这只是托管测试数据的替代品。
根据我的经验，开发人员选择共享数据库的唯一原因是他们相信在最近的生产数据上开发和运行在某种程度上是“真实的”，这意味着他们可以在测试上投入更少的精力。他们更喜欢互相踩脚并忍受在下一次生产更新之前慢慢损坏的共享数据库，而不是编写和管理适当的测试。正是这种管理实践给 IT 世界带来了目前所拥有的糟糕声誉。
于 2012-01-25T06:27:28.790 回答
-1
我建议使用数据库的一个实例。您不希望您的数据库成为移动目标。
于 2008-10-24T17:51:24.027 回答