在德国学Info中国同学的很多, 但是好像没看到有做DBA的, 基本都是做entwicklung了
本帖最后由 雪候鸟 于 2012-1-13 00:56 编辑各位XDJM们你们的项目是否也经常这样子: 大多项目初期时候都不考虑数据量的增长, 基本也不邀请DBA参与项目开发, 基本是entwikcler在数据库里搞东高西. 几年以后后台数据库就乱的不成样子, 成了很多企业的性能瓶颈而且Datenschiefstand多的要命. 这时候才想起来找些DBA来救火, 因为DBA从一开始就没有参与项目开发, 对业务不了解, 不能给出整体的Datenbank Konzept, 也就只能在些查询语句上做些调优. 如果只是做query优化，也不许要什么dba了。 主要的问题不在于有没有选这个方向，而是用人单位。你也说了，很多公司都没有单独为数据库做过预算，甚至认为excel或者access用做Datenbank就足够了。
纯数据库的工作位置相对较少，“没有”需求，自然没人选择，市场导向决定了学习方向。 dba处于一个support的尴尬位置，项目架构什么的和dba没什么关系，没有看低dba的意思，个人以为db tuning还是很重要的。 这个问题在于程序员缺乏数据库设计知识，不是DBA的责任，程序员需要自己知道数据应该如何组织设计。
如果楼主在SAP领域就知道了，数据库表格的设计完全是程序员的工作内容，和DBA无关。数据量的增长预期需要程序员能够前瞻性地设计。初级程序员仅仅是coder，只需要把别人写好的详细设计实现就行了。随着经验的增长，程序员不应该仅仅coding，也应该知道如何设计数据库表格。 imbiss 发表于 2012-1-13 08:56 static/image/common/back.gif
如果只是做query优化，也不许要什么dba了。
这位朋友小看查询优化了。毫不夸张的说，查询优化是相当讲究的，涵盖很多dba的知识。简单说一个例子，一般的程序员确实能够优化一些查询，但是经常想不到，按照系统不同的负载情况，一个数据库在执行同一个查询时候，所生成的查询计划是不同的。可能一个查询在系统cpu负载高，io负载低的时候数据库选择全表扫描来执行一个查询，在相反的情况下cpu负载低，io负载高的时候偏向使用索引。查询优化设计到硬件，操作系统，网络情况，数据库本身特性还有业务状况，数据分布等多方面因素. 本帖最后由 雪候鸟 于 2012-1-13 13:02 编辑
二十八亩田 发表于 2012-1-13 09:28 static/image/common/back.gif
主要的问题不在于有没有选这个方向，而是用人单位。你也说了，很多公司都没有单独为数据库做过预算，甚至认 ...
数据量小用什么当数据库真的无所谓。数据库量大就不行了，其实很多系统数据都没到TB级别，性能就差的不行了。其实对dba的需求不少，不过基本都是去救火，有点亡羊补牢了，是技术leiter的失职 qwycd 发表于 2012-1-13 10:14 static/image/common/back.gif
dba处于一个support的尴尬位置，项目架构什么的和dba没什么关系，没有看低dba的意思，个人以为db tuning还是 ...
错就错在项目架构和数据库关系不大了这点上了，太有这种情况了，有了hibernate什么数据库的东东根本不重要这种思想了 我们这儿开发是不能直接访问数据库的，所有改动都只能让dba执行 adgjl 发表于 2012-1-13 10:49 static/image/common/back.gif
这个问题在于程序员缺乏数据库设计知识，不是DBA的责任，程序员需要自己知道数据应该如何组织设计。
如果 ...
其实对于这个话题谈不谈sap根本不重要，因为所有企业应用都有这种情况。sap本身的表结构也不见的设计的有多理想，也偶儿看到sap自己业务表产生死所的情况，sap本身的性能也真不怎么好。另外把所有的事情都推给程序员去处理其实不妥，感觉sap程序员的大多业务不错，编程水平其实比c++, java程序员差些