如何处理好DBA与Developer的关系?

dinglang_2009

首先要说明的是，并不是所有的公司都只有1个DBA的。大公司里一般DBA是分部门或者组的，工作内容又分为开发DBA、维护DBA、数据库架构等等。大公司的分工相当明确，一般不会出现这种情况。
在中小型的软件公司，DBA的工作内容一般非常广泛。涉及到：建库建表、sql语句编写、存储过程/事务等开发、数据库性能调优、维护、备份、恢复、集群、容灾等等。有些还要参与项目前期的数据库设计。这样看来，就很容易和developers 的工作内容交叉了。如果任务和工作内容分工不明确，就很容易出现“各守自家的一亩三分地”的现象。
说到底，还是要分工明确。让团队中的成员，各自发挥自己的特长，互相帮助，这样大家都会进步。

devilkin0312

和dba对业务的熟悉程度有关，不熟悉业务，提出的优化方案不一定是合适的。
和dev对数据库的理解有关，不同的dev对sql的用法明显不同，比如做dba的去做开发，sql大部分会先考虑下性能。
和交互方式有关，一般dba和dev的交流方式注定了一个公司的数据使用规范化程度。

表示在和dev沟通问题一路千难万阻。

Obuntu

这个话题很好。。

mchdba

devilkin0312 发表于 2012-7-23 22:20
和dba对业务的熟悉程度有关，不熟悉业务，提出的优化方案不一定是合适的。
和dev对数据库的理解有关，不同 ...

表示，很有同感，曾经一度相互抬杠过。

hai503

dinglang_2009 发表于 2012-7-23 18:03
首先要说明的是，并不是所有的公司都只有1个DBA的。大公司里一般DBA是分部门或者组的，工作内容又分为开发D ...

让团队中的成员，各自发挥自己的特长，互相帮助.
就是这个意思。
“各守自家的一亩三分地”的现象，更多的时候是因为确实处理不好“融合关系”，不如就“国际惯例”。

hai503

甲方DBA和乙方DBA遇到的情况可能不尽相同：
甲方DBA针对的是相对固定的DEV团队，早期的“规则”一旦形成，之后很难更改。比如之前一直是DBA优化SQL，那要是想再让DEV来做，恐怕很难；
乙方DBA面对的是“流水的兵”，来自五湖四海，工作方式和方法千差万别。如果DBA在团队伊始就定好“规矩”，之后在项目中流动的“兵”，也会遵守大部队的“纪律”。

haojia716

DBA很多时候是在给开发人员擦屁股。

cyber_bss

观念上的影响 比知识上的传授更重要
可以适当吹吹牛，再多鼓励，夸夸上进developer
毕竟性能调优也是件很有成就感的事
有一两个主力developer有这种感觉
很容易就培养起技术崇拜的风气
也容易引导团队主动学习技术（包括性能相关技术）

eisen-pb

我倒是觉得DBA本来就是给Developer作后续的。
很多系统应用伊始空荡荡的，再差的sql也跑得飞快，随着数据量增长才会逐渐显出变化，而且随着不同应用场所不同的数据倾斜等情况，sql的调整自然不会一致，这时候也不能指望dev们，这个时候就是靠DBA灵活掌握，灵活调整的。
当然有人会说，dev一开始就应该预计到后面的发展情况，这个……觉得不是很现实，哪怕是很有经验的架构师，也不会做到料事如神的，而且作乙方的DBA和Dev这一点会感觉越发明显——各家客户业务重心不同，sql的改变方式差距之大哦……
所以我觉得，Dev就是负责把握业务逻辑正确精干，而各个应用场点的具体实现，则是靠着掌管各个不同DB的DBA们长期调整来实现最优的。

ses19828

这个涉及到2个岗位   人与人   人际交往    那就复杂了   
谈3个角度   3D分析  楼下的 可以画图补充：
1.为人处事角度 ： 没有谁对谁错，谁好谁坏     一件事情   不同的角度   换位思考  也许   就可以理解对方     
2.职责角度：谈到具体的某一件事情，关于SQL优化        2个岗位   “职责”范围的明确  很重要       职责范围的明确，精细分工。
3.管理角度：老大，明确SQL优化，谁发起提醒，指导，谁又是明确的执行法。 明确工作流程。。。。例如：DBA发起优化问题----开发人员+项目经理 接收问题---谁来明细分工该问题----流程才会接下去走。