萍聚 › 德国工作 › 在德国学Info中国同学的很多, 但是好像没看到有做DBA的, 基本都是做entwicklung了

雪候鸟 发表于 2012-1-13 01:44

在德国学Info中国同学的很多, 但是好像没看到有做DBA的, 基本都是做entwicklung了

本帖最后由 雪候鸟 于 2012-1-13 00:56 编辑

各位XDJM们你们的项目是否也经常这样子: 大多项目初期时候都不考虑数据量的增长, 基本也不邀请DBA参与项目开发, 基本是entwikcler在数据库里搞东高西. 几年以后后台数据库就乱的不成样子, 成了很多企业的性能瓶颈而且Datenschiefstand多的要命. 这时候才想起来找些DBA来救火, 因为DBA从一开始就没有参与项目开发, 对业务不了解, 不能给出整体的Datenbank Konzept, 也就只能在些查询语句上做些调优.

imbiss 发表于 2012-1-13 09:56

如果只是做query优化，也不许要什么dba了。

二十八亩田 发表于 2012-1-13 10:28

主要的问题不在于有没有选这个方向，而是用人单位。你也说了，很多公司都没有单独为数据库做过预算，甚至认为excel或者access用做Datenbank就足够了。

纯数据库的工作位置相对较少，“没有”需求，自然没人选择，市场导向决定了学习方向。

qwycd 发表于 2012-1-13 11:14

dba处于一个support的尴尬位置，项目架构什么的和dba没什么关系，没有看低dba的意思，个人以为db tuning还是很重要的。

adgjl 发表于 2012-1-13 11:49

这个问题在于程序员缺乏数据库设计知识，不是DBA的责任，程序员需要自己知道数据应该如何组织设计。

如果楼主在SAP领域就知道了，数据库表格的设计完全是程序员的工作内容，和DBA无关。数据量的增长预期需要程序员能够前瞻性地设计。初级程序员仅仅是coder，只需要把别人写好的详细设计实现就行了。随着经验的增长，程序员不应该仅仅coding，也应该知道如何设计数据库表格。

雪候鸟 发表于 2012-1-13 13:58

imbiss 发表于 2012-1-13 08:56 static/image/common/back.gif
如果只是做query优化，也不许要什么dba了。

这位朋友小看查询优化了。毫不夸张的说，查询优化是相当讲究的，涵盖很多dba的知识。简单说一个例子，一般的程序员确实能够优化一些查询，但是经常想不到，按照系统不同的负载情况，一个数据库在执行同一个查询时候，所生成的查询计划是不同的。可能一个查询在系统cpu负载高，io负载低的时候数据库选择全表扫描来执行一个查询，在相反的情况下cpu负载低，io负载高的时候偏向使用索引。查询优化设计到硬件，操作系统，网络情况，数据库本身特性还有业务状况，数据分布等多方面因素.

雪候鸟 发表于 2012-1-13 14:00

本帖最后由 雪候鸟 于 2012-1-13 13:02 编辑

二十八亩田 发表于 2012-1-13 09:28 static/image/common/back.gif
主要的问题不在于有没有选这个方向，而是用人单位。你也说了，很多公司都没有单独为数据库做过预算，甚至认 ...

数据量小用什么当数据库真的无所谓。数据库量大就不行了，其实很多系统数据都没到TB级别，性能就差的不行了。其实对dba的需求不少，不过基本都是去救火，有点亡羊补牢了，是技术leiter的失职

雪候鸟 发表于 2012-1-13 14:04

qwycd 发表于 2012-1-13 10:14 static/image/common/back.gif
dba处于一个support的尴尬位置，项目架构什么的和dba没什么关系，没有看低dba的意思，个人以为db tuning还是 ...

错就错在项目架构和数据库关系不大了这点上了，太有这种情况了，有了hibernate什么数据库的东东根本不重要这种思想了

tadios 发表于 2012-1-13 14:06

我们这儿开发是不能直接访问数据库的，所有改动都只能让dba执行

雪候鸟 发表于 2012-1-13 14:10

adgjl 发表于 2012-1-13 10:49 static/image/common/back.gif
这个问题在于程序员缺乏数据库设计知识，不是DBA的责任，程序员需要自己知道数据应该如何组织设计。

如果 ...

其实对于这个话题谈不谈sap根本不重要，因为所有企业应用都有这种情况。sap本身的表结构也不见的设计的有多理想，也偶儿看到sap自己业务表产生死所的情况，sap本身的性能也真不怎么好。另外把所有的事情都推给程序员去处理其实不妥，感觉sap程序员的大多业务不错，编程水平其实比c++, java程序员差些

雪候鸟 发表于 2012-1-13 14:14

tadios 发表于 2012-1-13 13:06 static/image/common/back.gif
我们这儿开发是不能直接访问数据库的，所有改动都只能让dba执行

看来你们公司有层次

德国足球加油 发表于 2012-1-13 16:51

有些coder连范式和闭包都不懂，就开始设计数据库，出来的活能好吗。

raymanxxx 发表于 2012-1-13 17:29

如果你公司把你定位成数据库专家，那么可以考虑给自己更合适的名称。 比如Database Developer，在开发过程中积极参与进去。否则 如果仅仅是DBA，顾名思义，A for Administration. 很多情况下的确仅仅是各support的职能。保证运行之类得的。

公司的开发模式决定了你得长处能不能用上。如果公司不明白数据库开发的重要性，只知道找个人管管就够了，那肯定是公司的失误。反过来说，如果公司数据库开发都交给database developer。而楼主的职位就是管理，那么也没有必要特别的去较真。换各开发的位置更合适发展。

mies 发表于 2012-1-13 17:38

雪候鸟 发表于 2012-1-13 13:10 static/image/common/back.gif
其实对于这个话题谈不谈sap根本不重要，因为所有企业应用都有这种情况。sap本身的表结构也不见的设计的有 ...

诚恳的问一句业务指的是什么?

adgjl 发表于 2012-1-13 19:12

业务是指对企业流程的了解。

灯笼果 发表于 2012-1-13 21:24

数据持久层框架查询语句不是自动进行优化吗， 难道还自己写sql query 内嵌进去

江南织造 发表于 2012-1-13 22:02

我们公司的DB相关的全部包给IBM了.....{:4_297:}

雪候鸟 发表于 2012-1-13 22:34

灯笼果 发表于 2012-1-13 20:24 static/image/common/back.gif
数据持久层框架查询语句不是自动进行优化吗， 难道还自己写sql query 内嵌进去

这就是我刚才提到的，觉得有了hibernate数据库就不重要了。hibernate能做的优化太有限了，在数据库层上加一层orm, 其实是为了更面向对象。但是面向对象，也不是银弹，过于OO经常要损失效率的。假如一个业务不太多的小电信公司的CRM, 因为并发不高数据量不大crm用Hibernate问题不大。尽管业务不多，但是后台负责电信计费系统的系统，每天的电话通讯记录也是多得要命，根本不用想hibernate了。这种场合基本都是unix和c，c内用sql了，这些sql是需要找高手调优过的。

雪候鸟 发表于 2012-1-13 22:34

江南织造 发表于 2012-1-13 21:02 static/image/common/back.gif
我们公司的DB相关的全部包给IBM了.....

看来你们用DB2吧，什么行业阿

雪候鸟 发表于 2012-1-13 22:36

本帖最后由 雪候鸟 于 2012-1-13 21:36 编辑

adgjl 发表于 2012-1-13 18:12 static/image/common/back.gif
业务是指对企业流程的了解。

是的，saper业务一定要精通。其实我也想搞sap, 单位70%的业务也是sap的，内部调动下也不难。但是实在是舍不得现在的同事和领导

雪候鸟 发表于 2012-1-13 22:39

mies 发表于 2012-1-13 16:38 static/image/common/back.gif
诚恳的问一句业务指的是什么?

业务这里是指企业的业务流程

江南织造 发表于 2012-1-13 22:43

雪候鸟 发表于 2012-1-13 21:34 static/image/common/back.gif
看来你们用DB2吧，什么行业阿

汽车行业, 老实说我们用啥我没有了解过, 但是基本所有数据库相关的全部包给IBM了, 据我所知, 不少公司都是这样的, 所以我觉得ibm咨询这块应该很赚钱

雪候鸟 发表于 2012-1-13 22:44

本帖最后由 雪候鸟 于 2012-1-13 21:44 编辑

江南织造 发表于 2012-1-13 21:43 static/image/common/back.gif
汽车行业, 老实说我们用啥我没有了解过, 但是基本所有数据库相关的全部包给IBM了, 据我所知, 不少公司都是 ...

你们是不是服务器也是webphere,企业门户时websphere portal

雪候鸟 发表于 2012-1-13 22:52

江南织造 发表于 2012-1-13 21:43 static/image/common/back.gif
汽车行业, 老实说我们用啥我没有了解过, 但是基本所有数据库相关的全部包给IBM了, 据我所知, 不少公司都是 ...

汽车行业还是不错的，我在电信行业工作还是觉得有点累

江南织造 发表于 2012-1-13 22:58

雪候鸟 发表于 2012-1-13 21:44 static/image/common/back.gif
你们是不是服务器也是webphere,企业门户时websphere portal

这个我也真是不知道, 估计只有我们it部门才清楚.......{:5_383:}

雪候鸟 发表于 2012-1-13 22:59

江南织造 发表于 2012-1-13 21:58 static/image/common/back.gif
这个我也真是不知道, 估计只有我们it部门才清楚.......

你不是我们码农队伍里的啊

某兔 发表于 2012-1-13 23:01

hibernate有自己的缓存层和lazy load机制, 效率也不一定很差, 另外hibernate也可以支持native query, 如果有必要的话也可以手动做sql的tuning. 我觉得数据量真的大到一定程度的话, 不妨可以考虑一下现在挺火的no sql数据库. 牺牲一些数据质量, 提高读取速度.

雪候鸟 发表于 2012-1-13 23:04

本帖最后由 雪候鸟 于 2012-1-13 22:06 编辑

某兔 发表于 2012-1-13 22:01 static/image/common/back.gif
hibernate有自己的缓存层和lazy load机制, 效率也不一定很差, 另外hibernate也可以支持native query, 如果有 ...

恩同意你的观点。不过效率是相对的而言的。例如我们项目里有些sql一次要返回1GB的数据，而且没有必要lazyloading, 因为这些数据都是马上就要用的. lazy loading的本质就是动态的proxy, 在读取延迟加载的时候hibernate生成sql. 对于高并发系统来说sql parsen的时间也是不可忽略的

灯笼果 发表于 2012-1-13 23:06

雪候鸟 发表于 2012-1-13 21:34 static/image/common/back.gif
这就是我刚才提到的，觉得有了hibernate数据库就不重要了。hibernate能做的优化太有限了，在数据库层上加 ...

大型数据库不是有扩展性吗，数据量访问大的话会放到不同的服务器上， 具体到集群的实现是只用硬件还是硬件和软件的结合这个不是DBA可以做得了的吧

江南织造 发表于 2012-1-13 23:20

雪候鸟 发表于 2012-1-13 21:59 static/image/common/back.gif
你不是我们码农队伍里的啊

我是做系统Vorausentwicklung的, 不用码字 {:5_383:}, 我们公司的码农都在印度, 或者是我们自己想好要什么东西, 然后去IBM之类的公司, 他们来做解决方案, 告诉我们行还是不行, 然后直接给我们开发相应工具包括数据库. 象工业界的一些公司, 都把大部分纯it业务外包出去了, 自己做从投入上不划算

查看完整版本: 在德国学Info中国同学的很多, 但是好像没看到有做DBA的, 基本都是做entwicklung了