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

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

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

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

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

当然,我们需要脚本来更改数据库,而一切都在源代码管理中.

数据库环境应该稀缺的日子早已不复存在.我正在XW9300上写这篇帖子,里面有5x15k的SCSI磁盘.这台机器将在相当合理的时间内运行大量的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是我熟悉的几个示例)将允许您在单个工作站上为单个开发人员免费或以名义价格使用该系统.

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

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

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

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

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

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

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