开发人员和数据库管理员的角色如何进行转变？
在过去几年中，就开发人员如何在工作中和数据库“共处”有了很多转变。其结果之一是：数据库管理员（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相关，相信都有所体会。如果你愿意分享相关经历和体会，可以在评论或微博中分享。
转变之前
在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相关，相信都有所体会。如果你愿意分享相关经历和体会，可以在评论或微博中分享。