本期我们邀请到的嘉宾是数据库开发与代码规范专家：丁俊先生（ID:dingjun123），本次采访更多的是分享了丁俊先生的数据库结构，以及从oracle的发展领域和趋势方面做了深度的分析和介绍。

hwayw：
    您先自我介绍一下？分享以下您的职业经历？您目前的从事的工作？？

dingjun123：
      大家好，我的论坛ID是dingjun123,头像是个流浪兔，常活跃于ORACLE各版块以及海区、菠菜区等。

       说起职业经历，我可能没有过多的跳巢经历，工作已经6年有余了，回首望去，恍如数天尔，但却感觉自己都老了，呵呵。一直在某从事电信系统建设和维护的服务商工作，从事过系统开发、业务和数据分析、架构设计、数据库维护工作，目前主要侧重于负责电信级业务监控分析系统和电信级全量业务自动化问题追踪和验证系统研究和建设等工作，这两项工作在通信运营商领域应该是非常超前的。

    凭借您这么多年的工作经历，目前在国内的在哪些领域开发时使用ORACLE数据库，使用ORACLE数据库方面有什么优势？

    ORACLE市场占有率这么高，几乎遍地都是，只要稍微有点规模的企业，基本都能找到ORACLE的身影，而我所在的电信行业，BOSS、CRM等系统，主要的数据库还是使用ORACLE,经分系统大部分使用DB2。

    针对ORACLE数据库本身（当然ORACLE不仅仅有数据库，其他的也会对ORACLE数据库有影响），与很多其他数据库相比，我就不比较具体的体系结构和技术等差别了，说4点我认为比较重要的方面吧。

    ORACLE数据库各种文档齐全，咱们可以在官网上找到你需要的任何ORACLE特性的文档（当然internal的东西比较难找，不过也有很多流出来的，但是我认为这不是重要的），比如10g的PL/SQLPACKAGE文档已经达4000+页。另外还有专门的海量support知识库metalink,是非常棒的。其他数据库，我想从知识库建设上，与ORACLE比较，就稍逊一筹了。

    ORACLE从各方面不断完善自己的产品，每次发布new features都非常多，从10g的网格计算加入很多自我管理的特性到11g对这些特性的增强以及optimizer的不断改进和智能，比如11g的ACS(adaptivecusor sharing)功能，到即将发布的12c,可以看出，每次ORACLE新版本的发布都会给业界带来很多惊喜。

     这是对第2点的补充，第2点主要说的是ORACLE数据库的管理和维护特性强，那ORACLE数据库重要的一点是在于系统的应用，那么强大的开发特性支撑是必须的。

     ORACLE数据库具有强大的SQL语法支撑：比如MERGE、WITH子句（11g支持递归）、CONNECT BY、分析函数、扩展GROUPBY,多表DML、正则表达式支持、XML操作等功能，而且这些功能是在不断发展和改进的。就算简单的DML操作还支持基于INLINEVIEW的DML，是对普通DML的有力补充（性能优化常用）、丰富的built in函数也是ORACLE一大亮点。另外，大家如果研究过一些比较的文档，比如DATA CARTRIAGE DEVELOPER,可以看到还支持USER DEFINED AGGREGATE FUNCTION,这是非常棒的功能。也就是说，ORACLE的自定义扩展功能也非常强大。

     ORACLE数据库具有众多非常好的PLSQL特性：比如BULK PROCESSING、PIPE、JAVA PL/SQL 、EXTERNAL PRCEDURE、自动绑定和soft soft parse、各种CACHE机制以及11g的RESULT CAHCE、TABLE函数等。有的功能可以让使用者在SQL里使用PLSQL特性，比如TABLE函数。可以举个简单的例子：

scott@ORADB>    DROP TYPE c_emp;

类型已删除。

已用时间: 00: 00: 00.85

scott@ORADB>     CREATE OR REPLACE TYPE o_emp IS OBJECT

2                                           (EMPNO NUMBER, ENAME VARCHAR2(10),

3                                            JOB VARCHAR2(10), MGR NUMBER,

4                                            HIREDATE DATE, SAL NUMBER,

5                                            COMM NUMBER, DEPTNO NUMBER

6                                             ) ;

7       /

类型已创建。

已用时间: 00: 00: 00.15

scott@ORADB>     CREATE OR REPLACE TYPE c_emp IS TABLE OFo_emp;

2      /

类型已创建。

已用时间: 00: 00: 00.04

scott@ORADB>

scott@ORADB>     SELECT dept.deptno,e.empno,e.job,e.sal

2      FROM dept,

3        TABLE(CAST(MULTISET (SELECT* FROM emp WHERE emp.deptno = dept.deptno) AS

4                       c_emp)

5                  ) e

6        ORDER BY 1;

   DEPTNO      EMPNO JOB              SAL

---------- ---------- -------------------

        10      7839 PRESIDENT       5000

        10      7782 MANAGER         2450

        10      7934 CLERK           1300

        20      7902 ANALYST         3000

        20      7369 CLERK            800

        20      7566 MANAGER         2975

        30      7900 CLERK            950

        30      7844 SALESMAN        1500

        30      7654 SALESMAN        1250

        30      7521 SALESMAN        1250

        30      7499 SALESMAN        1600

        30      7698 MANAGER         2850

已选择12行。

     虽然这个例子本身意义不大，但是这种PL/SQL与SQL可以相互交互的特性，是很有用的，从另一方面说明SQL与PL/SQL是相辅相成，不可分割的，在ORACLE数据库中随处可以找到这样不同知识点具有紧密关联的特性，这有待于使用者自己去体会和挖掘。

     这不用多说，铺天盖地的名家和ORACLE布道者BLOG,各种专业站点（比如ITPUB）等，ORACLE自己也建立了很多宣传途径，比如认证、ORACLE MAGZINE、ACE计划、各种商业和非商业的活动等。

      题后话：ORACLE文档群体庞大，特性众多，该如何学习呢？请搜索ITPUB，ITPUB很多类似的讨论和精华文章。比如经典的tom大神的 oracle study road map.

                               

    有人认为进行大型开发项目时，只需要考虑程序系统的架构，不需要数据库的架构，您觉得这样的说法是否合理，为什么？数据库架构会对项目有什么影响，是否会对项目的成功的与否有直接的影响？

dingjun123：
这种说法我该赞同吗？当然是否定的，这种说法极其不合理，如果是小型系统，并发用户少，数据量小，那么数据库架构可能对系统的影响较小，但是只要是大型数据库应用系统就离不开大量数据以及高并发，这样的系统对数据库架构的要求非常高(当然，存储、网络、系统级设计等要求也会增多)，而只有数据库的架构合理，才能更有利于完成数据的高效读取操作。

数据库架构对项目的成功影响非常大，尤其是大型项目中，而且会随着并发的增加而成倍放大，比如源头数据有重复记录，如果不通过中间层过滤处理，靠下游的DISTINCT来排重，必然导致应用中大量的DISTINCT写法造成的排序，而访问的数据量由于大量重复逻辑读也比如很多，而这些下游的应用越多，造成的影响就越大。这只是举个例子简单说明一下，现实中案例不胜枚举，比如电信行业经常会因为业务的迅猛增长和数据库压力等因素而对系统进行改造，比如各种库的拆分，这是一个非常大的动作，主要原因就是前期架构考虑不周。

    对海量数据进行操作时，有什么值得注意的吗？优化是否对稳定性有影响？
     dingjun123：
     海量数据操作需要注意的地方非常多，我只简单的说如下两点：

     1.  历史数据如何处理。

     不管是什么数据库应用，都有历史数据和当前数据的区分概念，正所谓有进必有出，事物应该具有矛盾和正反面的特性。历史数据有静态和访问不频繁甚至需要清理等特性。海量数据库由于数据量庞大，所以一定要在架构设计的时候就考虑这个问题，典型的就是可以考虑企业级分区表的特性来处理历史数据，可以通过分区消除查询当前数据，可以利用truncate  分区来清理垃圾数据等。

      2.数据操作是查询为主还是更新居多。

     因为对于查询而言，利用索引查询数据在很多情况下是高效的，但是索引对DML操作性能缺不佳，因为需要维护索引。因此从中找到平衡就非常重要了，适当的建立索引首先就是要去了解数据操作是查询为主还是更新居多，必要的时候要考虑读写分离机制。

     关于优化，我觉的对稳定性能影响是很大的，举两个很简单的例子：

     单条SQL性能不佳，执行一小时多方可完成，耗尽单个CPU所有资源，假如该SQL是5分钟扫描一次的定时任务，一小时后将耗尽所有CPU资源（假如该系统有12个CPU），假如优化之后1s到2s内搞定，效率迅速提高、资源使用急剧下降，那么是多么美妙的一件事啊。

     典型的OLTP系统开发没有考虑绑定变量，虽然开发对数据分布比较清楚，BUT很多开发包括很多的开发，主要关注于开发语言，而忽略基于数据库系统的特点，没有考虑绑定变量，出现问题，需要求助DBA，DBA上去就弄个cusor_sharing=force,OK，可能短时间起到效果，但是谁说的准呢？可能一个本来好好的SQL，突然遇到skewdata,因为force,OK，会导致问题。就算similar也存在一定的BUG，有消息说，在12c里已经把simliardel掉了。就算ACS，估计也会有一定的问题，不要遇到新特性就去盲目尝试，使用有潜在危险的新特性需要大量测试,需要量化数据的支撑。

     第1个例子说的是优化产生正面的效果，第2个例子是说盲目优化可能会产生负面效果。优化需要权衡、需要优化前后的局部性能数据和全局性能数据的支撑，过度优化或影响全局的优化都是有问题的。你要知道，对于银行、电信这样的单位来说，那就是钱啊。

    有很多人认为，一个好的数据库架构可以保持数据库的稳定运行，但是不会对数据库的迁移、数据的灾备恢复等产生多大的帮助，您是否认同这样的观点？为什么?
      dingjun123：
      还是从大型数据库架构上说吧，从这个点上说，我是不同意的，小型数据库，管你咋整呢，需求和处理问题各方面都不是很复杂，东西一大，就麻烦了。

    您是否可以给未来数据库从业人员分享一些代码规范，数据库架构方面的经验和心得？以及给这些人群一些从业方面的指导？

     关于代码规范，在我们剑破冰山章中王保强先生(ID:bq_wang)已经有了详细的分享。此外，我在开发版的帖子：http://www.itpub.net/thread-1413182-1-1.html，也传了一些精心收藏的代码规范。

     代码规范很重要，比如有的人写PROCEDURE,参数名不规范，比如procedure p(name in varchar2),代码体里用wherexxname=name,但是，这个表里就存在有name这样的字段，OK，问题出现了。比如a and b or cand d,甚至可以更复杂点，如果你不知道and和or的优先级关系，还当成是((a and b) or c) and d用呢，有没有问题，很明显的答案，举个实例，因为类似的代码优先级问题导致条件不对，某电信运营商发生批量用户欠费迅速增加，从领导到下属都受到处罚，严重影响公司信誉。so,我对代码规范的认识就是，必须培养代码规范的敏感性，当对感觉可能有问题的代码，要特别慎重，因为，那可能就是将来要出问题的地方，然而，规范化的代码习惯，必然减少未来某种错误的发生的可能性。

     关于数据架构方面，前面已经说了，以业务需求为驱动。我觉的了读懂需求，读懂需求的前提是必须做好业务知识的储备和理解。准确了解业务始终是要放在位的，否则一切都是空谈，比如系统类型是OLTP还是OLAP啊，预测的并发量，数据增长等情况，都需要进行通盘考虑。

      举个例子说明业务与技术结合的重要性，曾经我做过一个数据采集流程改善和优化工作，2年多来，那个项目的某些数据采集，一直存在问题，采集的数据很多不满足用户要求，用户也知道业务非常复杂，没有人清楚业务到底牵涉到多少东西，所以，一直忍，一直做治标不治本的优化工作，效果都不是很好。后来，忍不下去了，找我帮忙优化和进行流程改善，我首先得学习业务啊，请教相关业务专家，可是业务专家毕竟不是技术专家，懂点技术。写了很复杂的优化流程，但是我要把这些流程固化到系统中，会发现有很多问题，复杂啊，而且有的不对啊。所以，我del掉他们的方案，再次请教一个非常的纯业务专家，聊了很多，发现业务的需求其实分为几大类，每个大类不同业务需求，OK，采用各个击破的方法，有针对性地解决某类问题，重要的一点是使用了ORACLE的一些SQL特性，做了些数据过滤，终几天内就搞定了这个问题。所以，我说，技术和业务的结合是非常重要的，技术人员积累了业务知识，会运用正确的技术技术精准地为业务服务，技术和业务尽量多懂点，后你会发现，你解决问题选择性更广，也可能把原来很复杂的问题简单化，这是很重要的。

      关于就业方面，我觉的现在工作竞争压力比较大，应届生可以考虑降低姿态，你要知道，年轻就是折腾啊，多折腾自然就成长了，甭管折腾的过程中有什么挫折。如果的确自身技术或学历有限制，甭管份工作，先干了再说，只要和你目标的工作类似。我以前一同学，毕业份工作还要交押金的，干了3月，一分钱没有赚。但是，他了解了他的目标，OK，机遇来了，进了西门子，后来到德国西门子总部混了两年，现在混的不错。

      在工作中切不可忘记学习和总结，不具备持续学习能力的IT人，必然不适合IT工作，被淘汰也是必然的，当然，如果在养老的公司，自己愿意过那种养老的生活，也可以休息休息，多点时间和朋友家人聚聚，也是不错的人生。毕竟大部分人还是刚毕业几年的经验供以后若干年使用，工作是为了更好地享受生活，不要太累着自己，IT人压力真的是很大的。

     您参与编写了已经出版的《剑破冰山—oracle开发的艺术》销量很不错，能给大家简单介绍一下这本书吗？分享一下您当时写作的一些心得？

     dingjun123：

    《剑破冰山》这本书是众位斑竹在ITPUB开发版长期服务的基础上，挖掘一些不错的知识点，结合自身经验和技术长处，关注案例分析以及一些ORACLE重要特性的这么一本ORACLE技术书籍。比较侧重于使用ORACLE有一定经验的工作人员，当然，如果这些内容对你没有什么用，可能觉得没有什么意思，但是如果正是你迷惑的地方，可以为你解惑，这正是我们的写作初衷。

      写作心得，说简单点吧，学习技术必须得总结，好记性不如烂笔头。从以前在学校学习到工作，我都喜欢总结，原来是用笔记本手记，我记的笔记大学里估计都是10来本，后来工作了，技术笔记也有5本以上，这些笔记对我工作初期帮助很大。后来流行玩论坛、BLOG等，我有幸接触ITPUB、**等，就玩论坛了，BLOG呢，没有怎么写，发现长期写BLOG有点累（非常佩服长期写BLOG的人），还是按照自己的方式学习总结，把一些认为比较好的内容放到网上分享。所以，OO说要准备写这么一本书的时候，长期总结的习惯和素材，就让这些内容自然出现了，当然，写书还需要把内容进行重构，毕竟是面向大众的，写书也可能要顾及大部分人感受，把知识点写厚，而读者要做的就是把知识点读薄，所以呢，书的内容，如果有觉得有邋遢冗余的地方，还请多多包涵。

社区ID:dingjun123

丁俊  某大型电信系统建设提供商工程师，6年电信行业从业经验，关注J2EE企业级开发和设计、LINUX/AIX、web2.0、ORACLE数据库开发和优化、逻辑和物理数据库设计等。ITPUBORACLE开发版和海区斑竹，ITPUB2010佳精华获得者，《剑破冰山-ORACLE开发艺术》副主编。

更多往期回顾：http://www.itpub.net/thread-1480316-1-1.html