数据库管理员的角色是否已终结?

在过去几年中,就开发人员如何在工作中和数据库“共处”有了很多转变。其结果之一是:数据库管理员(DBA)和数据库相关开发人员的职责发生了改变。那我们一起来看这些转变是如何影响开发过程的。

转变之前

在C/S年代,DBA的是系统管理员(专攻数据库支持)和开发人员(创建各种视图、存储过程、函数等)的混合体。为了最佳性能,DBA必须知道如何优化硬件和OS配置。为了最佳性能,DBA也需要有大量技巧,比如,表分区、建立/调整索引等。此外,DBA还要处理安全问题;DBA日常工作中最为普通的一件事是:创建一个有访问限制的存储过程A,把A提供给所需的应用程序,并且要保持基础表锁定。

另一方面,开发人员一般完全受DBA支配。DBA有访问数据库的全部权限,DBA只给应用程序或其他用户授权应有的权限。因为开发人员往往不善于数据库设计,所以DBA只允许开发人员模拟数据库。此外,很多开发人员并不像DBA精通数据库,他们的SQL代码性能往往不高,故DBA也限制开发人员运行自定义的SQL语句。

然而,在很多公司/机构,这些差别和角色分工已经不存在了。一些IT部门让开发人员有完全访问数据库系统的权限;在其他案例中,开发人员基本上已等同DBA了。但是在大公司,这种劳动分工一直都是非常普遍存在的。

有哪些转变

开发框架和系统已是翻天覆地,所以开发人员很容易运行数据库相关代码。各式各样的开发系统推出(Visual Studio 2005),最终让开发人员可以运行参数化SQL代码,而不再需要把SQL语句连接成字符串(这样使得系统会遭受SQL注入攻击)。同时,借助像数据仓库/BI等系统,开发人员可以创建自定义的SQL代码。对于大多数目标而已,由技术娴熟的人员调整过的生成代码已经足够好了。

对象关系映射(ORM)系统方面已有很大进展,比如Hibernate和.Net Entity框架在数据库上层新增一个抽象的附加层。如果开发人员能完全访问数据库,ORM非常容易使用。另外,借助.Net中的LINQ to SQL和Rail的AREL,开发人员也可直接轻松和数据库“共处”,比存储过程更为简单。

最重要的转变是各种敏捷开发技术的出现。现在,项目需求(数据库模型)可以根据客户的要求灵活变化,而且,需求变更的实现在2周的Sprint当中就可以实现,并看到效果。而在以前,这种客户提出的需求变化要等上好几个月才可以看到对应的实现。等待DBA更新数据库模型、更改存储过程和视图等等,然后再让开发人员根据数据库的更新来调整程序,这样的一个过程在敏捷团队中要经历很多的Stage。 所以,在这种环境下,开发人员通常自己创建并打包数据库,把它交给自动化的部署系统,由系统来更新数据库。

前景如何

这会不会意味着传统DBA角色已经终结了呢?我看还没有。我们仍然需要DBA,但在很多公司/机构中,他们正处于下坡路。

数据库仍然还有一套不同寻常的性能,不管是普通公司,还是像拥有《全球10大终极数据库》的大公司/机构,都需要一位或一批经验丰富的专业人员来规划和调整系统,以达到最佳性能。除此之外,现有的遗留应用程序安装数量很大。另外,在很多应用程序共享的数据库环境中,DBA需要协调其他东西(通常是用合适的事务举措编写存储过程),以确保应用程序“互不冲突”。开发人员可以忽略而DBA不能忽视的东西之一就是数据约束。

开发世界变化日新月异,不仅DBA和开发人员受此影响,其他很多角色也不例外。不管你是不是DBA和开发人员,只要你和IT相关,相信都有所体会。如果你愿意分享相关经历和体会,可以在评论或微博中分享。

 

Via:Tech Republic  编译:伯乐在线 敏捷翻译 – 关关
转载请注明原文来源和链接,否则视为侵权!

收藏 3 评论

相关文章

可能感兴趣的话题



直接登录
最新评论
  • 匿名   2010/10/05

    由于DB厂商的产品趋向于易管理,门槛没有以前那么高,一般的数据库相关的工作程序员也可以做得来。所以,我赞同DBA的需求量没有以前那么大。但更深入、专业方面,还是必须要由DBA来负责。DBA短期内不太可能终结!

  • 匿名   2010/10/06

    翻译的极差,不要拿机器翻译的啊

    那我直接给Google翻译一下不就等了

  • 匿名   2010/10/06

    @2楼游客:
    不知你是怎么看出此文是机器翻译的?

跳到底部
返回顶部