你还敢说，SQL Server你很了解？
zjcxc (邹建):我主要是用SQL Server的，所以这个话题基本上偏向于SQL Server.这个话题主要是来自于招聘，做了近1年的DBA招聘，简历看了无数份，有一个问题一直很郁闷:看到过不少的简历有这样的描述:精通SQL Server, 擅长性能优化及数据库维护
然而我在面试时问：
题1:
有两个表
t1(id) t2(id)
------ -------
1 1
1 1
SELECT *
FROM t1 a, t2 b
WHERE a.id = b.id
的结果是， 答：
id id
------- ------
1 1
1 1
题2:
在数据库维护中，备份有几种模式，比如我们最常用的完全备份（怕面试者听不懂）？它们有什么区别？
答：
我都用企业管理器中的向导，它很方便的了，上面写得很清楚
这就是精通和擅长
其实上面的问题对于做一个专职的DBA来说，应该算是比较起码的要求吧?还是我要求太高呢?这也是我的疑惑之一。
在这里，我主要想大家一下，大家对于SQL Server，学习起来觉得容易还是简单，而你认为的，SQL Server觉得还可以，应该到什么程度。
SQL Server是“邪门歪道”?
sxycgxj:其实做为微软的产品来说，总是很容易上手的，这是微软件的风格;不过要往深学的话，就要有一点的条件和兴趣了。对于中国大的环境来说，没有多少企业的老总会把数据库的管理看的很重，所以这方面的人才也就相应的少了许多。有时市场也是人才多少的风向标啊。
WangZWang :RDBMS的难易程度是相对的，在学习所有RDBMS时，首先要掌握一些关系代数和一阶谓词逻辑等方面的知识，这样学习
SQL会更快些。在学习某一RDBMS时，首先要系统全面的掌握它的架构和运行原理，并逐步把它几块主干技术慢慢的去研究。
可以这么说，‘难易’可以从是否找到一个有效的学习方法来分析。Microsoft的产品入手易，精通难，自然与它那几乎'傻瓜式‘
的设计界面有关，SQLServer自然也是这样，如果每天也只是‘傻瓜式‘的去与SQLServer打交道，那自然永远都不能理解它的设计精髓。
Linux_9 :我刚进入软件行业三个月，以前在做销售。05年毕业于一个普通院校。大学期间对于软件的兴趣:0。毕业了，想做软件，大家都不给机会。基础实在恶劣!!!终于，有了机会进入软件行业。(感谢当时领导给我机会)我们公司的情况我可以介绍一下:公司成立多年。软件也是一直在投入使用。一直使用sql2000。但是，你现在在我们的代码里面可以找到n个 select * from 。没有人关心效率。也没有人学习。我由于基础差，被分出来写sql语句。因为领导觉得这个不难，有可以对数据库了解。近而了解整个系统。哈哈!所以我就来到了这个论坛。我们公司的数据库，没有索引，没有优化。拒我所知，没有什么高深的东西。就是一些表，再加用来做一些统计项目写的存储过程。前几天，我学会了用事物。因为以前没有人用过，现在要用所以我先学会了。以前的老员工终于觉得我还能混下去了。试用期马上结束，我真有些害怕。我们公司的数据库性能出现问题的时候。以前公司设计过一个软件，会通过这个清除以前几个月的数据。来提高性能。
andy1995:我认为关于SQLServer是入门容易，精通难。尤其是数据库的内模式。
jwt1982:SQL Server，容易还是难?个人觉得，看需要的深度，个人做数据库类软件开发4年多了，现在看以前设计的库结构、语句、逻辑关系，觉得有好多好多地方需要优化。可能对入门来说，数据库都很容易，在数据量小，逻辑关系相对简单，查询速度不会有什么区别就是使用ACCESS之类的东西也没有什么关系。但是我目前接触到的系统，很多表都是日加20W条以上数据的，以前的结构设计逐渐不成熟了，速度和效率出现了问题，但是我毕竟主要是基于程序开发，所以很多数据库层的优化做的就不足，很多时候我会分多表，数据层尽量少做处理，多数时间是把计算分开，比方说放到中间层计算一部分，CLIENT计算一部分，感觉，还是很累。现在对于邹建提的这两个问题的例子，个人觉得，MS-SQLSERVER使用超过半年都不会出现邹建所说的答案，只能说是应聘者以前仅仅是使用过，而没有认真的去了解过。不过邹建你们公司挺有魄力的，一下就招10个DBA，确实强，我们公司压根就没有这个岗位，服务器维护都是软件开发人员的事情，反正公司系统都是我们自己做的，所以维护也就是我们的了呵呵。个人觉得，使用到什么程度，需要到什么程度，究竟是简单还是困难最终取决于需要，如果仅仅需要个表格，那么，就是简单，如果做数据挖掘之类的工作，就比较困难。
ashzs :呵呵，我这里也在进行DBA的招聘。当然是使用SQL Server的。我们的招聘也持续将近一年了。也面试了几十个了。但是始终没有招到，现在我也在怀疑是不是我们要求的太严格了。我们要求的要至少有4、5年左右的工作经验。考虑到SQL Server的DBA较少，我们的招聘上一直都写Oracle或SQL Server而且倾向于招对Oracle更擅长的。其实看了这么多的简历，写精通的几乎成为一种时尚。我在看简历的时候侧重于工作经验，做过哪些项目。在提问题时候主要集中在面试者对基础概念的把握，也就是其对数据库最基本对象的掌握。如果基础过关再考察知识的广度、提出需要优化的案例...在考察过程中看其是否擅长思考和对问题的理解能力。但是一般在最基础的考察上，基本就没有人能通过。如果总招不到，只能考虑是不是从开发人员中培养了。至于SQL Server是难还是容易。平常使用Oracle和SQL Server较多。自己对这两种数据库的理解:Oracle是金庸武侠小说中的正派武功。练习和进阶都非常缓慢，但是一旦有几十年的修为后，再练其他武功会事半功倍。SQL Server是邪派武功。入门和进阶迅速，但是到了一定程度，会发现总是无法突破大限，而且再次提高的空间有限。研习其他武功的时候，还要经历从头学起的痛苦。
Haiwer:不可否认，SQL SERVER是最容易学的，但是，学了数据库不一定是DBA，这一点那个数据库都一样
SQL Server:何谓“精通”?
Antiquesoft:其实所谓的精通也是相对而言的!对于一个新手来说,能写Left Join也就是一种精通!其实随着我们学习的深入, 才真正知道什么叫精通!
wenyzh:我认为其实这并没有一个固定的标准，比如当你刚开始学的时候，你也许会觉得那些会那么一点点东西的人水平好高哦。但当你进步以后，你会发觉当初哪些所谓"高手"的方法也许很笨，你还有更好的解决办法(针对当初的哪些问题)。甚至再过一段时间，你还会发觉更好的解决办法。所谓"没有最好，只有更好"，大概就是这样的道理吧(类似的还有学练武术的过程等等)。因而，我认为你招聘人首先应该设定一个标准，看看他们的水平有没有达到或超越你的标准，仅此而已，简历上写的都是他们自己的标准(也许仅仅是为了撑撑门面而已)，不必当真的。真金不怕火炼嘛。
zjcxc:只是从招聘中，看到的似乎是DBA这个职业还没有得到认可，感觉无论是企业，还是求职者本身，大部分对DBA都没有太深的看法，感觉对个人的职业生涯是个冲击。我对职业的看法:需求非常广泛的，往往意味着竞争大，待遇低(因为大家都容易看到这个职位，求职者众嘛);所以有代码工人之说(我不是想贬低，精通编码的还是需求者众，而不是求职者众)。需求不太多，但有前途的，应该还是不错的职位，比如DBA/BI，相信软件开发和产品生产一样，迟早是流水线生产，不同的点会有不同的专职人员。
lnhndx:兴趣和经验的积累很重要!没有5年左右的倾心接触，就自称“精通和擅长”是不可信的，我认为。逼近知识面那么广、内容有那么多!而我正在入门，从Sql语句的实现，开始培养起兴趣，再慢慢深入和拓宽。很多朋友是不是也是这样认为的?
coolingpipe :写精通可能也是无可奈何的吧。(中国化的东西，相信大家都能理解)。感觉云中客说的很有道理。个人觉得T-sql还是比较数据库管理容易一些，因为管理方面的东西实践太少，本人基本上算是一窍不通。相信中国的大部分软件企业里数据库管理方面的实践可能都很少吧。
li_zero :深入sql server还是比较难的。首先觉得容易上手，联机帮助很好，但是慢慢觉得很多问题上联机帮助就不够了。另外，数据库的应用中，性能是很重要的，但是sql server这方面有时觉得不好琢磨，资料不够，等待、锁等关键问题及其解决都不好找资料，只有去国外几个大的sql网站去找呀找，麻烦。有时遇到奇怪的有时出现有时不出现的问题，去微软新闻组找微软的人也不知道，这是很烦的。
hxd001_810:我感觉，SQL Server入手容易(因是RDBMS的典型代表之一，符合普通人的思维逻辑)，然而，要想真正成为SQL Server编程或设计高手，加上若没有很好的大型数据库开发项目的实践、磨练，我想没有个5年以上的接触它，是impossible!更别说会成为什么DBA了!就是说“性能优化”这4个字，其中包含的技巧、经验、能力以及对T-SQL等的理解。
zjcxc(邹建):如果我去应聘， 我会写精通;如果自我评价，我还是会给自己定义为熟练。
SQL Server DBA长的什么样子?
fellowcheng:其实无论什么知识和技能，入门总是简单，而且进展很快;但是要精通就得长期持之以恒，且和个人天赋、环境等有关，所以精通的人总是少。
bulletCoderHope:对sqlserver水平也没有多大的要求,熟悉一下权限,存储过程,触发器,事务,备份就很满足了.才学不久,以前一直学access的,感觉入门是非常容易。非常同意他的观点:可惜不是在上海招聘，我也是DBA，水平如何不敢说，说SQL Server容易的十有八九都是程序员，因为对他们来说，掌握了基本的T-SQL语法就能写出满足业务需求的程序来。
AI1983 :这问题我能答出，但我不知道我算不算DBA，也不知道什么程度算DBA(也许是那种只用存储过程就能编出一套进销存软件的人吧，呵呵)，反正很模糊。我想大部分的DBA不是很忙就是很轻松，轻松是因为这公司只让他做DBA的工作(至于都包括什么我也不太清楚)，忙的则要什么都干了，尤其是在一家除了你没一个人是电脑专业，譬如装系统，作网线，告诉人家EXCEL中排序在哪，WORD 中居中在哪，还有就是喊“我的数字怎么按不出来了”(我想大家一定会想到是什么原因的)，呵~真是悲哀
winterProgrammer :我个人觉得:数据库设计;数据库程序员(负责数据访问，也就是存储过程编写);DBA。这三个是不同的角色!各个角色的擅长都不同，当然，他们是很有联系的。
gaojier1000:目前作为一个纯粹的DBA工作，我还没有实际见到过，而且我看了很多的地方的招聘信息，均没有单独招DBA的，基本都是兼职的，个人在青岛，经常去人才网看，但至今没有发现那个企业要招聘DBA这一职务，企业需要的可能不是要求数据库性能提高多少，更关注的是你什么时候把任务开发完成，我卖出去，至于性能，是客户的事情了。而那些买了软件的再想，可能是自己的硬件配置不高，提计划买硬件。很少有人关心数据库本身的性能提高。当然，我也不是专职的DBA，我也是兼职的。
viptiger:我觉得DBA应该熟练掌握的是怎样控制和管理数据，并确保数据可以被程序安全可靠高效的使用。关于用什么样的DBMS应该不用太操心吧。
net205:个人感觉国内专职的DBA少，开发的大部分就是一些基本的数据库操作，好多事情都丢给提高硬件(像性能)来解决。再者像上面说的mssql入门容易，精通难，我就知道些插入/删除/修改/，多个表的join，一些存储过程，触发器，事务之类的，其他复杂点的就不懂了。
panjinfu80 :我不是DBA，但我的简历还是写了“精通”两个字，如果不写连面试的机会都没有的，这也许是一种障眼法。自己的水平自己最清楚。当然被问倒了问题，就没有后戏可言。
zjcxc(邹建):如果光会写select语句, 连会出什么结果都无法知道, 你说还能保障他写出来的东西是实现了正确的业务逻辑吗? 何况题目是针对DBA的, DBA都无法把握语句的正确性, 还必须去计算机上运行一下, 你说凭什么保障他能管理好数据库? 管理不好数据库, 剩下的摊子谁收拾呢?像我们公司, 很多数据都会通过replication流转的, 搞错一个数据, 可能倒下的就是好几台服务器, 这个责任谁也负担不起.
zjcxc(邹建):再回复有的人提到的, 在计算机上多半都做得出来. 为什么我要笔试的问题。DBA的一个重要职责就是要把握好迁入产品环境的sql脚本的质量, 如果你大部分的常规sql语句都要测试后才能把握结果, 那你如何能把握sql脚本质量? 对开发人员提交的一堆存储过程都去运行一遍吗?看起来似乎是一个好办法, 但你得清楚, 你运行的不单单是查询, 还要更新/删除等一堆东西, 不见得有这样的环境供你测试, 而你的结果是一大堆数据, 你不见得从一大堆数据中能查出什么.重要的是时间, 没有那个企业承受得起这么低效的代码检查时间, 何况DBA与开发人员的比例基本上是大于1:50。所以, DBA要求的是能从脚本直接知道结果是什么, 这不会要求是能测出全部的, 但至少是绝大部分的(开发人员写的脚本绝大部分也不会是非常规的脚本, 所以不用担心会有特别难的)
selectplayer :to zjcxc(邹建) :
您说‘DBA的一个重要职责就是要把握好迁入产品环境的sql脚本的质量’，我完全同意。但是据我自己的经验，许多时候问题还是在联机测试中发现的。我在一家数据服务公司，不大，主数据库就100G左右，常用表的几百个。我跟这些数据混了3年了，不敢说每个表的字段都记得，但是大多数都明白，还是要经常看字典。所以我单凭阅读代码，是不可能发现所有问题的。而且作为一个技术人员，有时还不能确切知道数据的业务含义。数据有它的特殊性，昨天还在好好运行的代码，今天就出错了。原因就是数据变化超出了预期。您可能会说，代码写的不严密，没错，完全严密的代码存在吗?‘DBA要求的是能从脚本直接知道结果是什么’，应该的。前提是你对数据足够清楚，知道类型、范围、约束，以及表间联系等等...否则,我晕。所以，在下以为，测试是必要的。可以发现错误，发现损失的效率，修改出可靠高效的代码。
libin_ftsafe:对于SQL Server 2000的应用，可以分两个方向:
(a)SQL Server数据库管理和维护DB Administrator
(b)SQL Server数据库设计和开发DB Designer & Developer
(a)方向，属于DBA高手们修炼的必由之路，需要比较系统的学习和掌握WINDOWS NT和SQL Server的架构，姑且把这些基础当作内功吧;
(b)方向，总体而言，容易切入，上手快，但是到一个阶段之后就会受迫于内功薄弱而难有大进，我的兴趣就一直集中在这个方向上，没有足够的耐心和决心去修炼内功，早就走到穷途末路了，呵呵。
绝大多SQL Server使用者都集中在(b)方向，但因为SQL Server 2000本身的某些特征，导致了其DBA数量并不多的局面，因此，也迫使部分开发者不得扮演起类似于DBA的角色来。
zjcxc(邹建):to: selectplayer() 测试和DBA属于两个不同的职能, 我不否认在开发过程每个环节的重要性, 但单说某个环节重要,能就有问题了.我这里主要是说明DBA应该达到的技能水平
lalakid :似乎都认为SQL SERVER 很容易学。我不这样认为，SQL SERVER是容易上手，加上中文的帮助文档，HOHO，似乎一切就这么多了，万事OK了，SQL SERVER2000的帮助文档我看了不知道几遍了，现在是越来越不想看了。刚开始学习SQL SERVER的时候是在学校，感觉帮助文档真是不错，尤其是都有例子，复制粘贴就可以，但是现在发现，这些东西都是在告诉我们怎么用，只是简单的使用方法，涉及到数据库原理的东西，往往说的不够，不管怎么说，还是有，关于数据库实现的内容，根本就没有，出去买书，也买不到，我个人认为，所谓的数据库优化，如果真正想做到，那么数据库实现是必须要精通的，至少是熟悉，一个DBMS开发出来，都是有他的方向性的，他的实现原理，决定了他的总体性能，也决定了怎么去用，才算是优化。
