是否每个开发人员一个DB?

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

我强烈建议每隔一段时间将staging数据库复制到developer数据库,以同步结构(或者更好,使用一个从头开始重建数据库的工具)。

数据库环境本应稀缺的日子早已一去不复返了。我在一家报纸上写这篇文章 XW9300

出于以下原因,开发人员应拥有一个或多个自己的开发数据库(IMO):

• Redgate SQL Compare Pro 他们为此做了大量繁重的工作。

• 鼓励应用程序体系结构,以方便配置管理和部署,因为人们必须部署到自己的工作站上。许多部署问题在投入生产或人们甚至意识到可能出错之前很久就会得到解决。

• 它鼓励开发人员承担一定程度的责任,因为开发人员必须学习基本的数据库管理。这也消除了对操作支持人员的许多需求,以及一些开发人员和操作人员之间的摩擦。

• 如果您有自己的数据库,就不会有任何守门人阻碍实验或其他工作。由于没有“服务器”,管理“服务器”的政治就消失了。

• 对于小数据量,普通PC的速度足够快。开发人员版本或许可证可用于大多数(如果不是所有的话)数据库管理系统,并将在桌面O/S上运行。如果您使用Linux或Unix,这一问题就更少了。对于更大的数据量(最多包括大多数MIS应用程序),请使用工作站(如 HP XW9400 或 Lenovo D10 professional development tooling . (是的,我知道这是双重许可证,但QT的商业全平台许可证大约是4000个座位)。 像这样的机器运行ETL过程的速度比您想象的快10到100百万行。

• Control-M 只需预感一些运行时脚本。 如果您对环境具有这种级别的控制和透明度,那么您就可以生成一个经过严格测试的部署过程,这在很大程度上消除了在生产部署中相互指责的机会。

我见过一些小型团队在14个环境中工作,同时有7个活跃在工作站上。在数据库繁重的工作(如ETL)中,您需要处理整个表,在单个开发环境中工作会造成时间浪费或花时间在蛋壳上。

此外,您还可以为数据库平台使用单用户开发许可证,这可以节省仅在数据库许可证中使用工作站的成本。大多数开发者许可证(微软和OTN是我熟悉的几个例子)都允许您在单个工作站上使用该系统,单个开发者可以免费使用或以名义价格使用。

相反,共享开发服务器上的许可条款往往有些模糊,我见过供应商多次试图说服客户在开发服务器上进行许可。

理想情况下,是的,每个开发人员都应该有一个“沙箱”开发环境,这样他们甚至可以在将代码部署到共享测试/暂存环境之前测试代码。

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

为每个开发人员提供自己实例的成本低于多个开发人员试图在共享环境中一起测试易失性更改而导致的混乱成本。

另一方面,在许多IT部门,系统使用复杂的基础设施,涉及多个应用服务器或多个物理节点。然后经济发生了变化;与为每个开发人员复制工作相比,人们合作并避免相互干涉工作的成本更低。如果您集成了昂贵的第三方系统,而这些系统不为您提供多个开发环境的许可证,则尤其如此。

我的建议是有两个级别的开发环境:

开发集成环境由所有开发人员共享,用于确保在将其交给QA之前,一切都按照预期工作。代码从源代码管理中签出并安装在那里,并且只有一个服务器实例(db或其他)。

拥有一个开发者数据库并不一定意味着你需要它托管在你的本地机器上。您可以拥有一台中央DBMS主机,其中所有的开发数据库都位于该主机上。优点是针对目标数据库开发的Garaunte。开发设备上的开销更少,为强大的IDE和应用服务器提供更多的空间/马力。缺点是所有开发人员的单点故障。(DBMS服务器宕机,没有人可以工作。)缺乏开发人员设置和管理DBMS的经验。开发人员无法像实验一样轻松地使用即将发布的DB版本或备用DB选项来解决棘手的问题。

我在本地安装了SQLServer Development Edition的一个实例。我们有一个QA DB服务器,以及多个生产服务器。所有开发和集成测试都是使用我的本地服务器(或其他开发人员本地服务器)完成的。新版本将被转移到QA服务器。每次发布,经客户验收后,投入生产。

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

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

• 您有大量的开发人员需要资源(我们部门可能有80名)
• 每个开发人员都需要多个资源(通常我每天使用4-5个不同的数据库)
• 最新数据很重要(只是刷新速度不够快)

我喜欢开发人员使用本地版本的想法 被隔离-开发模式更改、性能测试、设置特定场景等。。。

我认为这里有一个术语问题。我已经有一段时间没戴DBA帽子了(天哪,快10年了)——所以其他人可以插话纠正我。

我认为每个人都同意每个开发人员都应该有自己的沙盒模式集。

在MySQL和Sybase/MS SQLServer中,每个数据库引擎都可以支持多个数据库。每个数据库(通常)完全独立于其他数据库。因此,您可以拥有一个数据库引擎实例,并为每个开发人员提供其数据库空间,以便他们按照自己的意愿进行操作。唯一的问题是,如果开发人员正在使用tempdb,那么可能会发生冲突(我认为,您需要查找)。请注意,不要使用具有固定数据库名称的跨数据库查询。

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

我们的每个开发人员都有一个本地数据库。我们将创建脚本和“标准数据”转储存储在SVN repo中。我们有大量的测试,必须通过这些测试数据。我们还有一个“沙盒”数据库,人们可以将他们想要共享的数据放入标准数据中。这对我们很有效,允许开发人员修改其本地数据副本以进行测试,但我们可以控制传递给其他开发人员的内容。我们还严格控制模式更改,因此不会遇到其他人提到的问题。

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

这也取决于你所处的发展阶段。可能在早期阶段,您不想被连接性、网络和分布式环境问题所困扰,只想启动并运行。在这种情况下,当产品达到某种成熟度时,可以先从每个用户的数据库实例模型开始,然后再切换到中心模型。

在我的公司,我们在处理非琐碎的新功能时,往往会复制整个数据库。存在磁盘空间的理由是便宜的,而意外数据丢失(即使是测试数据)则不是。

我在这两种类型的开发环境中都工作过。就个人而言,我更喜欢拥有自己的DB/app服务器。然而,使用共享基础设施进行开发可能有一些好处。

最主要的一点是,共享环境更类似于现实世界的场景:当所有开发人员共享一个数据库时,您更有可能发现锁定或事务的问题。给每个开发人员自己的数据库可能会导致“它在我的数据库上工作”综合症。

然而,如果您需要应用和测试模式更改或优化,那么我可以看到这种设置中存在的问题。

您的整个模式(和测试数据)都在源代码管理中,对吗?正当

每个开发人员一个DB。毫无疑问。但真正的问题是如何编写整个数据库的脚本,“控制数据”,并对其进行版本设置。我的解决方案是: http://dbsourcetools.codeplex.com/ 玩得开心内森。

数据库模式应该保存在源代码管理中,开发人员应该同时拥有代码和数据库的变更集。在签入之前,开发人员应该处理自己的数据库。签入后,自动构建(例如:签入时、夜间等)应与应用程序本身一起更新中央集成数据库。

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

根据我的经验,开发人员选择共享数据库的唯一原因是他们相信在最近的生产数据上开发和运行某种程度上是“真实的”,这意味着他们可以在测试上投入更少的精力。他们更愿意互相践踏,忍受共享数据库在下一次产品刷新之前慢慢损坏,而不是编写和管理适当的测试。正是这种管理实践给It界带来了它目前所拥有的糟糕声誉。

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