2006年中国首届杰出数据库工程师评选面试实录_冯春培 毕业学校

2006年中国首届杰出数据库工程师评选面试实录(第一批)

来源: 赛迪网  时间: 2006-8-13

    “主持人：各位来宾，大家上午好！欢迎大家光临由中国计算机报CSDN网站、上海市计算机协会、北京计算机协会、IBM独家赞助的2006年中国首届杰出数据库工程师评选中选现场现在开始！我是中国计算机报郭旭。

7月3日通过网上答题的公选，今天30名工程师将分6组分别进行中选面试 ，他们将接受最严格的评审。为了显示本次评审的公平、公正，我们将在赛迪网、新浪网上进行图文直播，同时在现场邀请了几十位数据库业内人士。下面我先介绍一下本次评选的流程共分三个步骤，第一步是选手进行评述，每人三分钟，专家向该选手提问，总共十分钟。最后一个流程是评委点评，十五分钟。下面介绍一下参加本组专家罗小沛老师，周龙老师，唐世渭老师，另外还特邀了一位嘉宾，王云老师主持本场讨论。

参加第一组的选手有一号选手胡波，二号倪泳智。三号邢海捷。四号选手万正勇，五号选手王涛不能来到现场。

一号：大家好！非常荣幸有机会能够参加本次活动，能够跟各位优秀的同行交流，跟各位顶级数据库大师有这么一个学习的机会，我本人是国家烟草局行业技术维护中心的系统维护组的组长，主要负责全行业烟草的维护工作，目前主要接触的数据库产品是IBM DB2的数据库，从03年之后主要的经验是做IBM DB2数据库比较大的一些项目，其中包括了北京移动、兰州移动以及天津移动的BI数据库的建设，最近一直在做国家烟草转卖局一号工程的系统维护工作，在03年之前也从事SQL数据库的建设，取得了SQL的认证，以及IBM DB2的认证。

在这几年的工作中也积累了一定的经验，希望借本次机会能够和大家一起交流，互相探讨，谢谢大家！

主持人：下面请专家提问，从罗老师开始。

罗老师：你到烟草工作的时间在这数据库中做了什么具体工作和关于数据库的工作你简单说一说。

一号：烟草局的行业分析系统，我是这个航母中的前期系统规划，另外包括项目中间的实施，一些技术功课，和异构数据库架构的建设，另外在后期维护里面。

另外在大型数据中心的建设上，应该怎么和应用，后台怎么能够配合应用，怎么实现满足客户的需求。另外，行业用户纤长的环境是相当复杂的，可能会有多种数据库环境在里面，比如说会有IBM DB2的数据库，也可能有SQL的数据库，在异构数据库环境中怎么给用户提供一个统一的用户接口保障异构数据库之间数据的交换能够以一个标准的接口来进行，以及在不同的数据库之间性能是怎样进行匹配，我觉得这都是在经过几年项目过程比较有收获的一点。

周老师：我提个问题，你曾经做过北京移动ODS项目，你怎样理解ODS，它的数据库在哪？以及你要建ODS平台的时候你觉得主要是克服那些困难和解决哪些关键问题？

一号：北京的ODS项目，ODS就是可操作系统的存储，它和数据仓库比较大的区别就是只是引入了各个数据源的数据，但没有在数据上进行OLL（音译）跟前台的展现，也就是说没有做KB（音译），在ODS项目中比较大的特点就是说要以比北京移动项目为例，要在北京移动的各个业务系统中抽取数据，比如说北京移动的核心数据是BOSS系统，计费系统，这是重要的系统来源。来源CRM和财务ERP都是整个我们系统的数据源，我们的目的就是把不同的数据提供一个统一的空间，抽取的准则就是我们所关心的这些数据。数据仓库，ODS只是北京的一期，二期就是整个数据仓库的建设，二期就是在抽取上的数据上面再进行OSP（音译）的在线分析，引入趋势的展现。还有另外一个比较大的特点就是我们一定要保证多少数据质量是符合用户要求的和行业要求的，所以在ODS里面可能有这么两个特点：一个就是我刚才说的和不同的应用系统打交道，另外就是我的数据质量一定要满足行业的要求，因为数据质量也是数据仓库成功的必要因素。因为以北京移动这个项目为例ODS主要的数据库后台是DB2的，DB2来分析数据库，达到14个节点，像BOOS数据库和财务ERP都是SQL的，所以我们从不同的数据里面抽取ODS数据库里面就存在一些数据的转换，这也会引发数据质量的要求。

周老师：你的工作经验主要在DB2和SQL，你怎么比较这两个系统？针对不同的应用怎么来定采用那种系统？两种系统的优势不足？

一号：这个问题涉及的范围可能比较大，我尝试的说一下。因为我前几年的经验也是用SQL，但SQL的项目集中在ORPP项目中，我用DB2的系统主要是用在类似于数据仓库、报表分析的项目中，我的感觉SQL和BB2都是业界非常领先非常优秀的数据库产品，我有一点比较深的体会，谈一下DB2的S（音译）的数据库。

像超过10个项目以上的数据库中，我想SQL分析数据库有一个非常有意思的特性，数据库各个节点都有自己的硬件资源，都有自己的日志，发起一个SQL都是分布在各个节点上运行，在项目实施的时候通过跟踪会看到发起一个SQL的请求，是分布在每个分级上面的，也就是说每个分区都会有自己的CPU资源有自己的内存资源甚至有自己独立的日志，也有单独的存储，这样的在比较大的存储中在分区内比兴来设计我们的应用，就是说非常关键的地方就是要考虑数据平均分布，也就是说我们在建一个表导入一个数据的时候怎么让我们的数据非均衡分布在我们每个分区中，另外就是IO的考量及折算才能保证我们充分利用DB2的特性实现性能的优化。

另外，谈一下SQL，他也提出了自己的RRC架构，也就是说多个节点共享一个实例，我更多的是在概念上进行的，在大的概念中其实可以，是我的一点心得，数据的运行处理得性能可能没有DB2这方面处理性能强，为什么呢？因为它一方面是多个节点共享一个事例，肯定会涉及到资源的消耗问题。另外，它在发起SQL的请求，RRC的架构只是在SQL里面进行运行的功能，在表中发起APLT（音译）修改的请求被我们会发现应用并不是平均分布在我们每一个节点上面的。

另外一个方面，SQL在开发的功能上面提供了非常好的函数，一些比较好的功能能够给我们用，但在DB2函数的功能上面我觉得在开发上面提供的稍微差一点。

主持人：其他选手也可以向一号选手提问，没有吗？一号选手的时间已到，下面有请二号选手进行个人陈述。

二号：各位评委、各位专家大家上午好！我简单一下我的数据库经验杂谈，我可能接触的数据库角度或者一些方面比较多，主要是在数据库教学和理论里面，另外就是行业应用和数据库管理，我觉得自己的经验比较多，但不一定每部分都很深入。

实际上我做过很多门的网络教学、网络课件，在这方面主要是数据库第三版的CIO就是多媒体的补助软件，和第四版的网络课程，这在2005年的时候被评为国家级课程。还有一些新世纪网络课程的项目经验，我主要谈一下在现在的教学模式上面的一些体会。

我觉得在我进行数据库教学的过程中，现在主要体现出的两点一个是以人为本，另外是立体化的手段，主要有几种表现，一个是人交互，计算机网络，数据库技术，和多媒体的表现和自助行，高效便利的检索。

下面简单谈一下数据库管理系统，实际上现在的整个数据库大部分是国外，一个是SQL一个是DB2、SQL Server，他们基本上都已经有10—20年，他们大部分在中国设立了公司，但在中国主要做一些测试的工作，核心开发工作均匀部分在中国。我本人主要参加的是Kingbase的研发，大概做了两年左右时间，也解除了一些数据库的那核或者相关的研发。对于研发经验我简单谈一下。一个是界面的友好，另外在开发方法不求最好，因为效率远远大于完美，现实和经验都不允许我们这样做。

第三点，对于数据库我谈两点感想，第一是沟通，意思是说我们要理解用户，才能和开发商合乎被用户理解，第二是双赢模式，国内用户使用国产数据库也能得到降低成本的效果然后更好的服务，这样达到双赢的局面。

最后讲一下行业应用的研发，一个在数据库设计方面必须做好全局的设计规划，因为设计越细致出现的问题可能性就越小，工作的效率就越高，等量的性能提升，在编码层面往往需要比设计层面付出更多的辛苦。

主持人：下面请专家对二号选手进行评论。

罗小沛老师：你刚才讲了一下开发的情况和应用的情况，开发和应用的关系是什么？

二号：开发是应用系统底层的开发，实际上这是两种不同的体验，实现首先要考虑确定客户的需求，我们开发的数据库系统本身是通用的数据库，所以不一定是面向某个领域的，在速度和领域上面是关键的地方。

在应用层面，大部分基本上是面向特定领域的，他目的性比较强，针对所考虑也是比较细致的东西。

周老师：今天是2006年中国首届杰出数据库工程师评选终选现场，你对评选杰出数据库工程师怎么理解？

二号：大部分现在想到的工程师是行业应用方面开发的比较多，我觉得数据库本身是个很大概念的对象，不单是包括行业应用，更多包括数据库理论的一些研究，还包括数据库引擎，或包括数据库系统本身的。我看这个选手基本上这几方面都包括，有一位是哈工大的，还有几位，当然这可能是他们自己研发的.

唐世渭老师：你在做DB2的同时也做应用，你能说出比较好的项目？顺便问一下做过应用系统的运行维护吗？

二号：我们开发完之后维护由相关人员，除非是真正他们不能解决我们才协助解决，直接运行维护不直接参加。

唐世渭老师 ：应用开发你能举你认为你这方面做的比较好的项目吗？说明你里头的角色及发挥得作用。

二号：我还是跟教学这方面比较多，我们学校的一个校园网络管理系统，这个系统是校园办提出来的，是把这几十年校友做一个系统，目标很明确一个是进行有效的管理，另外是找出有价值的校园资源，我在里面因为是负责人，另外还有负责人是校园的老师，开发是由我负责的，在这其中也参与了很多开发。刚才也提到数据杂乱的问题，大部分是一些资料，他们的存储格式和方法都不一样，原先想以一个为基础，把所有的导出来，最后发现太乱太杂了，最后决定充分规划。碰到的这一问题就是建模数据库的特点，我最主要还是要了解校友部的需求。

主持人：我们2号选手还有2分钟，专家还有没有问题？没有。

下面请二号选手进行陈述。

三号：各位朋友大家好，我叫邢海捷，毕业比较工业大学，工作十年来主要是做数据库的研发与维护工作，在工作中我体会到在数据库设计方面首先要强调对数据库的需求与了解，需求了解的越透彻数据库的构建才会更稳定，数据库设计也是一门平衡的艺术，可以根据情况适当增加数据库的冗余。

在开发方面我认为要加强数据库开发人员的培训，另外对于用户口令简短的数据现在不建议MD5算法，在数据库实施设备选购时我认为既要考虑当时的购买成本也要考虑日后的维护成本。还要非常重视原有系统数据的导入与转换，确保数据库的正确性，应该建立完善的备份与恢复策略，平时的实施监控与定期的数据库健康检查应该相结合，及早发现系统潜在的问题，做到防患于未然，对数据库配置都应该在测试成功后再用到生产系统中去。

对于数据库的优化我认为现在国家提倡建设资源节约型社会，我们应该把更多的精力放到系统的效率提升以及应用软件的优化上而不要过多增加硬件资源的消耗，还要增长团队精神并且不断学习新知识新技术有选择的应用到系统中去。最后我非常赞同三分技术，七分管理和十二分建设这句话，它充分的总结了数据库建设的经验与教训。谢谢！

主持人：请专家进行提问。

罗老师：我想问问刚才你比较系统的介绍了一下你的静音，在数据库应用里面我想一共有两个环节，一个是做设计一个是维护。你在这两者之间有什么独特的心得，另外在设计过程中你认为设计目前当前存在的问题和困难在什么地方？有没有比较完善形势化的办法把数据库设计做的比较合理合适？有没有这方面的想法？

三号：在数据库设计方面因为我不是搞理论研究的，从我原来工作实践中我觉得还没有形势化的做数据库设计的方法，我觉得在数据库设计方面跟软件一样关键是对需求的理解，要深入到工程的现场去调查研究深入的了解用户他们在实际应用系统中存在的问题，他们的数据流程是什么样的，根据他们现在的业务情况以及未来的需要设提出概念模型，在概念模型的基础上转换到比较系统逻辑结构上去，在逻辑结构设计时原来可能大家比较重视达到几泛式，从现在来讲从实际情况不必强求达到某种泛式。

在数据库设计上，很多经验不足的工程师开始建索引，因为索引的开销是很多的，也可能增加其他的开销，现在对于大量的数据可以采用分区方面的设计，还可以分散IO，因为IO的处理数据较内存和CPU还是有量级上的差异的。因为很多惨痛的教训就是因为没有做好备份，或者没有做好测试，所以在维护阶段最重要的还是要做好备份与恢复和进行有效的测试。

罗老师：你在运行维护中有发现调优的时候发现过什么问题？

三号：现在我在做一个专职DDA（音译），发现系统有效能方面的问题，主要先整个观察一下系统，比如说利用SQL的一些工具，比如说SP（音译）的数据库流量情况进行分析，找出关键耗费资源最大的SQL语句，然后对SQL语句做重点优化，另外有时候开发人员不见得非常愿意让别人去优化他的SQL，对他们进行数据库方面知识的培训，比如说我就把在实际应用中把发现的SQL问题抽出来，重点解析一些对比，优化之前和优化之后的差别，挑出来的实例大概基本上有十倍以上的差别，也赢得了对优化项目的赞同，所以最后经过优化以后首先我删除了一些索引和SQL语句，建立一些方面使整个数据库物理图都有大幅度下降。我们更应该把注意力放在应用与优化上，这样才能符合我们建设节约型社会的趋势。

周老师：你在陈述中谈到一个绑定变量，能不能用两三句话把它本质说清楚？

三号：主要指我们在写SQL语句的时候，我不太清楚这个概念跟编译原理是否一致，用SQL的绑定变量有什么好处呢，在同类建立原来系统的分析数执行计划，如果是用常量形式，如果第二次执行是另外一个常量，每一次运行SQL语句的时候都认为是不的SQL语句，这样就会增加系统的开销，这样在OLTP中系统中的开销是尤为明显的。

主持人：下面有请四号选手做陈述。

四号：大家好，我主要分三个方面来介绍我的陈述。首先是个人介绍，在这一点上由于时间的关系我就不做多陈述。第二点某保险公司大集中业务系统。（PPT）这是我们所建系统的现状就不多做介绍了。（PPT）这是比较有代表意义的，因为我们在做数据库的时候如果成本还非常高，今年同样的价格可能到了两年之后只需要一半的价格，价格是不断呈下降趋势。如果选的太少，在短时间内资源可能就不够了，必须增加服务器，对于某商业公司讲必须做运算，这个系统的现状是基于DHA的方案，有一些比较严重的问题，比如说可用性不够高，而且扩展性是比较差的，新的架构是基于SQL的运行来做的，是采用并行的方案来做的。

接下来我们要对服务器确定了架构之后要确定服务器进行选型，比如说三年之后设计我们公司应该收100个亿，这就是我们主要设计这个系统的主要依据，选型的服务器要满足三年内100个亿的要求，这块是我们设计的出发点，我来分析这个规划的出发点就是根据系统的保单数来算的，我做的事情就是把这100亿的报保单分解出来，比如说现在系统每张保单大概是根据这些数据分解出来就变成370多万的数据，最后就得出我们的服务器需要的处理能力是多少，接下来进行确定服务器的型号。

这几年的经验下来可能有一些经验和体会跟大家分享一下，要做好这件事情只懂数据库是不够的，我们需要对操作系统调优、对存储系统调应该有比较深刻的认识，如果要使这个系统维护的好，DDA要参与系统维护，因为我们的IT系统都是为业务服务的，所以你不能只懂技术还要懂业务。谢谢！

罗老师：第一个项目是分散的，在分散的系统到集中的数据结构方面有没有什么变化和考虑的问题？

四号：一个大集中的系统会对系统的压力更高，以前分散的系统，比如说分散的系统有几百人，那么就需要分散出几百个。我们要求的性能不是呈线性上升的，需要处理得性能不是说十倍的关系可能是上百倍的关系，第一考虑的是制成非常大的数据和并发用户数。还有一个问题，在系统性能没什么关系，纯业务上的，比如说编码的问题，以前每个分公司有自己的系统的时候，只需要考虑自己，大集中之后就带来另外一个问题，要对编码做整合，我们设计的时候要做一些特别的考虑的。

唐老师：在提问有关关系前先提一个非技术问题，在你的简历表上填的是中国寿险公司，是哪个公司？

四号：是PICC。

唐老师：刚说高级专家是什么意思？

四号：因为我走的技术系列所以就称为专家。

唐老师：你公司刚建立不久，是属于财险下控股的保险公司，你参与了这个系统的开发建设？

四号：对。因为现在金融行业有一个趋势就是以开发为主，之前的做法也有一些弊端，如果说一个需求出来之后要先到IT，然后再沟通，整个过程被拉的非常长，对用户来讲是非常不满意的。从设计阶段我们全程参与做设计，只是到具体我们的工作这块我们来做，整个运维工作还是由我们来做。

唐老师：下面我想问的是这样，因为你们是甲方单位，通常都选择了合作伙伴来进行开发？

四号：对。

唐老师：在系统建设中你觉得自己的位置在什么地方？因为这是个普遍模式，普遍模式作为大型企业在建立应用系统中通常都引用合作单位，作为甲方单位数据库工程师你觉的在这个时候应该做些什么能够使得自己有很好成长核项目的完成？

四号：我们会参考项目的标准，相对来说做寿险行业做数据库方面的是相对比较晓得，由于是全国大集中的系统，我们考虑要支持大数据量大多用户数的设计，在挑服务器的时候也需要一些特别的考虑，我们还做数据运维，一定要对数据结构有所了解，如果是外包公司开发的，就可能有两难的问题，如果不是基于操作是不会掌握实际操作的，如果不掌握运维工作是没法调整的。我想从外包的情况下对DBA有一些更多的要求，主要是对第三方的协调工作。

周老师：你们在设计这套开发系统的时候以后从该南分析和逻辑分析下来的，保险行业是一个很古老的行业了，全世界这方面的大公司有都是，你对他们的系统有没有什么了解或者借鉴？是自己从头做起吗？

四号：我这么回答吧，从整个国际市场来看确实是这样，应用都是非常广泛，这样的系统优势就是储存率非常强。带来另外一个问题就是对国内业务的支撑现状不是非常好，可能在国外看来都是不可能做的事情但在国内就来做这件事情。这样就带来一个，我们选择是国外的系统还是国内的系统，国外系统扩展能力非常强，基本能力都有，国内系统就是非常灵活，能想到什么样的功能都能够实现，而且成本是非常低的，而国内系统没有经过大业务量、大数据量的考验所以扩展能力是较弱的，一般我们会结合两方面系统的优势。

周老师：现在提倡要和国际接轨，特别是保险行业更需要这方面的需要，那么你们在设计开发的方面有可能就是会形成障碍，你是怎样考虑的？

四号：基本上因为国内的保险业务相对国外来讲是比较嫩的，我们要做的数据都会存起来，因为有比较好的模型，在设计阶段就会参考他的数据模型，做些参加做些变通，再加上国内技术的应用，国外的系统因为发展的时间比较早，所以技术是比较老的，使用界面是非常不友好，而且对汉字的支持也是不道微的。在实现上面我们会采用自己新的技术，像LP的概念，这样的系统就会相对比较好一点。

主持人：下面进入到五号选手（视频选手），王涛你能听到我的话吗？

五号：我主要是想说一下在技术支持关于项目费用的东西，对于技术方面也是相当重要的东西，现在都重视框架和SOA，可能感觉在座的各位都是各行业的高手，都是从年轻时开始积累到现在，很多人都忘了自己本身传统应该保留的东西，只是一味使用到了API，最关键是要理解数据库实现，并且是秉承的东西在一些项目中也是非常重要的。比如说前两天我把到了一个KS（音译），做业务移植，搞的很复杂，最终发现是卡在数据库方面，这种情况本身是用细节方面让它节省了，这种方法还是细节决定的，也就是细节决定成败。

主持人：有请专家对他进行提问，因为五号选手在多伦多实在没有办法赶回来。

罗老师：因为你现在在国外工作，你刚才提到细节决定思路，我很想了解在国外数据库工作经验中，你当然在国内待过，对国内数据库具体技术人员根据你的经验有什么想法和要求。

五号：我在论坛上也会经常看一看，在技术含量上有很小差别，尤其是美国很厉害的DDA（音译），在国内相比应该是强很多很多，国内感觉还是在考虑应该怎么样实现这种方法，但国外的人已经考虑怎样开始优化，怎样做的更好，国内不管是在开发和应用上还有很长很长路要走。

唐老师：你现在还在大学里吗？是在大学学习期间到IBM去技术支持做一年还是说现在已经毕业了，专门在IBM公司？

五号：我还没有毕业呢，现在做实习，实习是16个月，从去年5月份开始到今年的9月份结束，在这期间看了很多BLKS（音译），被技术问题难倒的东西，感觉挺恐怖的。

唐老师：现在对数据库的支持也是不同层次的，一个现在处在的位置是厂商对数据库运行的支持，很多是在运行单位系统集成商来支持运行系统，你自己这一年来的经历对应用单位负责应用系统支持这些数据库工程师们有些什么建议？

五号：还是应该了解这个层面的东西，毕竟看不到DB2源代码，还是有一定的问题，在美国摩根斯坦利他们有一些BUG，但他们对DB2的理解相当的深入，不会犯很愚蠢的错误，如果他们找到问题就真的是有问题了，在非IBM内部技术人士建议，多玩一玩DB2，有机会应该多参加一些DB2的讲座，这样才会理解的比较深入，在应用层面还是差的很多。

周老师：从你的材料来看DB2细节都还是比较深入了解的，发现一些问题的话的确从系统本身就有这个问题，你认为DB2这样的问题多吗？

五号：也就是说DB2的BUG？

周老师：从资料上看一些问题俗话是“硬伤”，DB2都搞了30来年了怎么还有这个问题啊？

五号：对于大系统不可能做到十分完美，只能让用户感觉在正常的操作没有问题，在极端的操作可能就会有一些问题，可能BUG比较多就会有DLOK（音译）这块，总之感觉到做的还好，不能决定说完美，因为不可能有一个系统是完美的。

主持人：现在时间也差不多，现在的提问环节到此结束，下面进入到互动讨论时间，有请特邀嘉宾王云老师主持互动讨论。

王云：我很高兴听到各位选手发表了他们的经验谈和老师们的很有价值的问题，我个人感觉到跟大家交谈之下，大家的经验其实都是很丰富而且很实在的，其实蛮感动。

先抛砖引玉提个问题让他们讨论一下，好象好几个选手都谈到国内遭遇到比如说大集中或者很多信息整合，自己也感觉到国内经过过去差不多十年IT应用阶段，现在确实到了整合的阶段，不管说地区上的集中，大集中把省市集中在一起或者应用集中和单向业务做集中，我们常常说计划赶不上变化，第一个问题跟大家交流一下在我们做这些项目实施的是，一个项目从开始，从需求开始分析到设计、规划、实施到最后上线和监控一直往下走。丢个议题讲，大家有没有谈一下这个经验，当谈到计划赶不上变化，当系统需要做变化的时候，不管是需求的变化或者做整合的也好，或者数据库做好怎么样把它做设计、需求也好做一个变化，在这样的过程中有没有一些难处，这个题目太大了，做一点再收容一点，有个选手讲规范，现在有一种新的想法，如果说想造一个系统跟别的系统互动的话，是不是有一个更灵活的数据模式，不知道大家接触没有？是不是用XML的模式做交换做存储，XML是不是代替我们的计划赶不上变化，以前提到怎样做变迁，XML是不是可能有帮助，大家有没有想到对系统做调整的时候是否提供出一个新的解决方案的想法，我觉得这是很有意思的话题让他们讨论吧。

四号：因为刚才王云老师也提到系统大集中业务变化非常快，就会有各个系统整合和再造的问题，解决业务流程和业务需求在设计的时候有一种服务的概念，按照厂商的说法叫做VP（音译），那么我们在设计时确实要考虑这样的服务，这样带来得好处就是我们在做系统整合的时候流程就是的时候，只需要把这些细的服务重新整合一下，这就涉及到系统之间的整合XML的方式，折算效率上会有很大的提高。各大数据库厂商也在XML这块做了非常大的供进，作我们的系统中确实也用了很多XML，比如对银行系统的交互交流和沟通都是用XML做的，这是一个比较好的方向，来满足业务快速的变化。

五号：我本身也是想说关于SOA方面的东西，已经被这位选手说完了，都差不多吧。本身SOA也是集成在小的模块中，跟大积木一样，通过接口，接口是固定的，通过XML。IBM大概在2000年提出的东西这是一个很好的东西。

王云：刚才万正勇你提到在保险行业中数据交换已经用到XML的，在你的经验中收到的XML的DAT（音译）怎么处理呢？

四号：相对来讲从纯XML应用还是比较少一点，更多还是在应用层面来处理的。

三号：我在上中学附中的时候听老师说低下头看题，抬起头看方向，最近有XML的话题比较热，在我们目前有限的预测能力之内可能是一个方向，前些日子参加了有关SQL的讨论，XML现在实际上是作为SOA数据交换的基础，可以说是半结构化的数据库领域，很遗憾没有使用DB2对V9，对XML原声的支持，我们用了一些SQLXML，只是做了一些试验，现在对于SOA和XML应用现在有两大担心，效率和安全性的问题是需要考虑的。我参加的会议上两方专家对效率上的问题都没有正面回答，从长远发展任何一项新技术它刚开始的时候都会有人质疑惑他的效率问题，比如数据库刚开始的时候很多反对者认为效率不佳，但是随着硬件基础设施的逐步提高和对各大厂商技术支持提高效率问题他们认为逐步可以得到解决。另外，安全性问题，现在我觉得可能是一个，尤其在外部方式下是一个比较令人头疼的问题，各个系统都不敢保证自己的系统是绝对安全的，比如微软和IBM逐渐对自己的系统发布补丁，发现漏洞等。采用SOA为基础的技术以后能不能引入更多的风险呢？

王云：讲到安全这方法来讲，SOA确实是现在很热门大家投入很多时间来谈的问题，你刚才提到性能方面的担心，你交流的时候其实刚的很好，你自己提到大家在设计数据的时候讲要广泛式，但你反过来讲必须跟你的实际情况做调整，你必须了解XML的数据模型带来得好处是什么，带来得好处应该说不能够多快好省，应该是对整个数据模型调试更好，这就是你讲我们在拼命在念书要抬起头来看一些新的技术，你交流的时候也提到要不断的更新看一些新的技术，看能不能帮助我们出席现有的业务更好。谢谢！

二号：很多选手有说到XML项目的问题，我觉得XML它可以适用于数据交换的模式，尤其在现在的多平台上面，但是就效率问题。

王云：你有没有试试看啊？

二号：现在用的MySQL，不知道现在的DB2V9有没有，我知道第8版是没有XML的支持。

二号：我记得当初V9不是这样的，有个专家是专做XML的，他一直在做这方面的技术，在目前大数据量的情况下一个是效率慢。

王云：你真的去存储的时候其实每一个重复的东西全是用内部代码来代表它，长话短说，我不会在这边讨论太多DB2的INT（音译），将来在做一个数据库系统的模式来讲对将来解决的问题，我刚才说的计划赶不上便不管说从DAT的数据上，或者业务整合速度非常快的时候，如果把业务的增长和表格的设计上，是不是XML可以简化我们的系统要变化的过程？

二号：目前可能大部分问题都是在数据交换上。

王云：从交换真的是要到存储对不对？

二号：在设计方面我觉得确实这种需求的变化是一种XML，主要用的化确实会解决不少问题。

一号：我在03年就已经开始碰到应用系统之间的整合了，包括在北京做ODS的项目以及包括现在做烟草行业的项目，目前建设的项目和历史遗留的项目进行交换一直是我们在做数据交换整合非常大的题目，我记得很清楚，03年我们做ODS项目，当时有两种放一种是把数据放到数据库中，另外是怎样对数据进行解析，再插入到我们的XML中去，本身应用的需要留给我们处理数据的时间是有限的，可能就两个小时左右，以上提供的两种方法都不足以采用XML的手段，它为各种不同应用系统提供了一个统一的接口，但是我们在使用DPR（音译）的时候在性能方面确实与系统的要求有一定差距的。

前两天参加了06年IBM开发者大会，对IBM力推的XML和SOA概念已经渗透了两天了，确实XML的存储技术我觉得还是比较激动人心的，因为目前我们做的烟草，它的有关很多历史遗留的项目，提供的接口是用XML来封装的，在不同的数据中实现数据交换也是最先我们需要关注的。昨天刚拿到600G的数据，准备搭建DPRDUIO的平台，看在大的数据量的情况下，如果处理系统的时间有限，看数据库引擎能不能满足我们的要求来限定这一块。

王云：听起来大家可能在业务上都有这种需求，大家都有所保留对性能上的支撑，刚才提到现在如果不使用这种技术的时候大家都在找一些其他解决方案，就感觉到其他的解决方案相对来讲其实也是成本也很高，甚至开发成本也会很高。

主持人：我想各位专家和各位专家有很多意犹未尽的话题，会后可以深入讨论。下面有请评审专家对本场评审进行点评。

罗老师：我想发表一下自己的意见。第一，各位选手都把自己所做的工作包括理论部分和实践的经验做了比较充分的阐述，我想是比较充分但不是完全充分，我希望以后的选手能够更好的把陈述这三分钟的时间利用起来，而且掌握好时间。大家都听过青歌赛，超时是要扣分的。在座有很多年轻同志，在数据库应用领域中做出很多工作，而且积累了很多经验，同时也听到在国外工作的学生，他把国外的情况业介绍到国内了，我觉得国内有一个很大的问题，在理论上在书本上的东西我们都用上了，但是我们经验的积累还没有找到非常的细致，像国外一样。因为他们有他们的问题，他们有包袱长期不能推掉，而我们国内，不知道烟草怎样，就是不行推倒重来，因为容易根基不是很深，因为国外的树很大我们的树很小。我希望在座很多有经验的选手在今后的工作经验上积累经验。所以就今天来讲，我没法评谁第一谁第二，但是不足之处就是需要各位选手接下来准备的更充足一些。

主持人：下面宣布本场评审到此结束。

 

 

 

2006年中国首届杰出数据库工程师评选面试实录(第二----六批)

作者:   来源:   时间: 2006-8-13 21:12:50 收藏本文 

主持人：群雄逐鹿“2006年中国首届杰出数据库工程师评选 终选现场”第二场现在开始！

我是中国计算机报的记者高雪鹃，因为我们选手有三分钟的自己陈述时间，你们一定要把握住，第二我们有一个互动的时间。我们这个环节每个人只有10-15分钟的时间，3分钟自我陈述，一分钟也不能超时，然后就是互 动。下面有请王晓刚做陈述。

王晓刚：大家上午好！今天很荣幸有机会跟大家分享我在数据仓库建设方面的心得和体会。

第一，数据库就是是为企业范围内建设统一的过程。

第二，坚持持续数据资源改进。因为数据质量是数据的生命。像国外的的词语所说的一样，我们要在数据库建设中持续资源改进”。

第三，我们要处理海量数据，同时我们对数据库要求快速的数据装载和及时响应，在响应方面主要是合理使用索引技术、数据分割和汇总也能够提供响应。

第四，我们在数据仓库应用中要融入先进的管理思想和方法，提升应用价值提高客户的管理水平。

第五，直观有效的用户界面，比如说地图分析和仪表盘，这些用户界面有比较友好的表现方式可以为数据库的表现方式增色很多。

再有一点，经过五年对IT行业的服务经验，IT本身是一种提供信息服务，我们作为服务人员必须要有好的技术和专业的服务经审核态度，“态度决定一切”，如果我们做到时为客户着想的话就会做好我们的项目。

主持人：谢谢，时间遵守的很好，下面有请评委老师对他进行提问。

罗老师：如何保证数据质量有没有量的要求？最近我看到有人写了一本书，好象是国家税务局写的，里面提出这样的概念叫做“零误差”，你认为从你的角度看来如何界定，一个系统的数据误差应该怎样来保证它算是比较科学的论述？

王晓刚：我觉得现在从目前我所在的行业是保险行业，处在初期阶段，当时的信息系统当时有很多种原因，数据的质量得不到保障，但这个项目我们做了很长的时间但数据还很难保证这个数据百分之百的准确，但给客户定了一个原则就是误差在5%之内。

罗老师：误差来源于什么地方？

王晓刚：客户的应用系统相对来说由于裸机关系可能不是很严格，我觉得数据的质量有些时间差，存积时间上有些不一致，还有统一口径方面额有些误差，当时的统计部门和销售部门可能他的关注点不一样，口径也不一致。

唐老师：有这么几个术语，数据仓库、操作数据存储、ODS、O SERVER（音译），你对这三个术语怎么理解？

王晓刚：我觉得数据仓库是核心的数据存储，包括原始的技术模型，会有汇总的应用。ODS在数据源和数据仓库之间是过度，ODS前边连接的是数据源，仓库可能会关注分析，大量的数据查询费用又比较高，ODS是一个过度，一方面适应数据源那边有很多数据装载，经过ODS处理之后，更方便的能把数据装载到数据仓库中。Server那边主要是做一些分析。

唐老师：数据仓库是这几年才发展起来的，以前只是数据库，你从你们的经验上来看是怎样过度过来的？因为原来都是数据库。

王晓刚：因为我在保险行业一直在做ODS，我们积累了很多数据，我们就需要把这些数据很好的利用起来来做一些用户支持等等这方面的应用，也要给市场一个快速反映。

唐老师：你怎么从原来的数据库怎样过度过来的？

王晓刚：当时过度是这样的，先过度核心业务系统，那时候做了集中的过度，我认为应该做分析，但当时没有做。那时候用的是ODS，现在用的是ORACLE。

主持人：有请段云峰进行三分钟的个人陈述。

段云峰：尊敬的各位专家各位同仁大家上午好！我的陈述主要包括几方面内容，有些东西可能会跳过去，首先做一下自我介绍，我是在北邮获得的博士学位，主要方向是做数据挖掘等方面。2001年进入中国移动通信集团公司，开始主持了分级是数据仓库，今年6月份设备容量达到1416TB，数据容量达到842TB，自己是整个中国移动数据仓库项目的主管或者说项目负责。而且在相关媒体也出版过两本有关数据仓库方面的书籍，在做项目设计相关过程中考察过美国最大的无线运营商。我们在项目管理过程中都技术了相关的工作，组织调配等等相关的工作，完善了数据仓库的理论，填补了这方面的空白。（PPT）这是我出版的两本书。中国移动数据仓库有些东西我就不说了，现在的竞争越来越激烈了，一个是数据网越来越多，数据的转接性比较差，系统较多，数据资源呈现为“自助网”现象，在美国的情况最好的应该是沃尔玛，他的水平是很高的。在国内电信和金融都开始进行了数据仓库的相关工作，这是一个现实的历程。（PPT）这是我们设计的数据库两级结构。有关这个主题是在2001年比较早的时候提出来的，整个中国移动创新点有如上（PPT）10多条。因为中国移动现在已经是最大的电信运营商，数据规模肯定要超过这些行业以及其他行业。在这里我们建立一个最大的数据库仓库，建立了统一的交换平台。设计了国际上第一个符合CWM标准的海量移动通信数据仓库元数据管理模型。实现了面向海量数据仓库全过程的数据质量管理体系。进行了有关的闭环处理，流程方面的结合。对于PMML的统一数据挖掘模型建模技术。提出了基于XML的导构系统统一接口技术。实现了面向海量、复杂、异构混淆的动态、增量式的数据抽取。中国移动的工程建设带动了一批经营上的水平，填补了国内的很多空白。经验总结，首先说难点，我刚才说这么大的数据量在国际上是首创的，我们采用了分级数据的理论，应用方面引用了报表相当于完整的一套应用体系，我们提出了有机结合建立结构，还有标准化问题，中国移动前后做了大量工作。数据质量这方面我们在元数据的基础上建立了一个数据质量的管理体系。人才方面现在是特别缺点的问题，因为现在国内刚才专家也提到，数据库方面人才及其缺乏，我们现在加大培训。项目经验有几个内容，数据仓库涉及到很多的感觉问题，质量十分重要，涉及多个方面，有必要加强对数据仓库领域的理论问题研究，数据仓库的数据标准化问题十分关键。（PPT）这是有关材料和相关证书，感谢专家指导！

罗老师：刚刚你介绍内容很丰富，光创新点就11个，当然在数据仓库建设中有一些经验和理论，我想问在中国现实情况下你刚才提到的难点和困难，你认为在技术上的难点和其他的什么因素，在这方面有没有什么可说和介绍的东西，讲完了好的东西还不足，因为建立一个大的系统毕竟不是很容易的。

段云峰：应该说是超大型系统，在建设过程中技术是第一个问题，尤其在数据仓库问题上，还有管理问题，还有数据质量问题，诸多问题实际上最后是在数据仓库中暴露出来的，如果要解决要保持联后联动，实际情况也是这样，在前期阶段，系统变更了而后面变成机制，这是一个简单的例子。第二，就是管理流程，流程应该说在数据仓库摸索这么多年最为突出的问题，理论上数据库建设是要打破现有的流程，这是公司高层需要理解到的。第三，是应用，在数据仓库中应该说是刚刚起步，在国外看了一下他的应用也不是像我们原来想象的那么丰富。在国内建这种大型项目或者说数据仓库项目不足点，我觉得一个是技术方面，和人才及其缺乏，从我们做的过程，举个例子，第一个是国内做研究的时候能够做人才的很少，我们都采取了一些方面做了一些考虑。第二个还是一个管理问题，更多的是技术驱动，他的特点是比较小，从一个小报表开始，中国移动当时采取的还是比较大的策略，把数据都统一规划再做后面的应用。刚才说到数据质量，罗老师刚才提的也是非常到点，最主要的就是数据质量，实话实说现在还是有一些小的问题，就是说现在不能解决所有问题。您刚才提的零误差，我个人认为工程上是不可能的，有诸多的定义，没法做到零误差，作为工程人员也很难做到这点。

唐老师：通过你对数据仓库建设过程和运行过程，如何看原数据在数据库中的重要性？

段云峰：唐老师应该说点中要害了，原数据是一个很重要的技术特征，原数据和数据仓库和数据库面临的问题是：数据仓库要解决的量要更大，原数据在原来的数据库中是一个数据字典的概念，但在数据仓库中我们引用了元数据的方法，我们在实践的过程中开始就很关注元数据方面的研究，包括CWW方面的研究，在国内就已经开始了，各方面做了大量的工作。通过各省的试点知道CWW标准是很重要的。在国内有这么大的数据库遵循国内标准这一点还是整个元数据对整个数据库建设是十分关键的。

周老师：你刚才提到中国移动这个大的系统在国际上是排在前面的，面临的一个很大问题是人才问题，我们了解我国数据仓库大概有十来年的历史了，前几年一直很热，几乎各个在培养开这方面的课，平时的论文也很多，这和你刚才讲的有一个矛盾，说明我国有这么一个好的平台，这么多研究机构培养了这么多人，这个事情好象是一个比较大的问题，你那儿觉得人才非常缺乏，可是从我们感觉上来说各个学校这十来年培养了不少人，说明了沟通问题非常大是吧？

段云峰：因为我也是学校出来的，了解其中的“行情”，国内一般是侧重数据挖掘和算法的研究，而在数据仓库这个领域里面，我举个例子，我们真正要这个系统的时候真正的设计，说白话是集成研究的时候确实感觉到人才十分缺乏，但是数据仓库是很复杂的系统工程，包括ETR和后端的应用是一套的东西，在高校测算理论挖掘这方面比较多，但在数据仓库这方面的人才相对比较少。我个人多说几句，数据仓库还是在数据库的基础上，在大的数据库真正按MPP理论做的都很少，很多的都不是纯粹的为海量数据夺的工作，因为中国移动也算是个个案，但是他代表了一个方向，部分企业已经意识到这么大的数据是一个近况，而且足够得多，足够的丰富，这一点应该说是一个过程，现在底层还是在关系数据库这方面来做研究。

周老师：我觉得这个事情是需要很好的沟通，我们现在已经有那么大的公司你们的题目做不出来，解决不了，这个问题可能国外的大公司经验还是要学习，把这个问题提的比较具体委托研究机构大写来做，这样可以非常良性的为国家水平的提高。

主持人：下面请三号选手盖国强进行三分钟陈述。

盖国强：各位专家、各位朋友大家好！因为我们有一个主题叫做创新性，我想把我们的实际工作经验总结做一下陈述，在数据库故障处理中引入故障树分析（FTA）的探索。当故障出现的时候我们怎样解决，这是我们做维护的人员面临的最大一个问题，我在工作中发现，故障树分析法也是很有效的一种方法。在一些企业工作流程或者说故障解决过程中，特别是在6、7个码的过程中这种方法是很被应用的，我们看到在我的图中，（PPT）数据库故障的一个结果，有那些情况可以导致数据库故障呢？可能有这三个方面的因素，第一个是来源原中间层，第二是来源原网络层，第三来源原服务器端或者说Server，我们进而对这三个层次进行分解。比如说客户端出现一些问题，比如说客户端的应用程序、驱动版本、客户端防火墙的故障问题。网络层也有一些问题，内网或者防火墙问题，带宽和流量的限制问题，如果数据库的服务器端会有这样一些问题，数据库的监听端口问题，Server端资源问题是否出现资源短缺，这可能是由于你的磁盘的问题、IO的问题、内存以及交换的问题和CPU资源的问题，这样很多都可能由于资源短缺引起的数据库故障，另外在应用层面的问题，是很多数据库故障的根本原因，应用层面的SQL问题，还有一些数据库的BUG问题，我们通过这些故障树原因把有可能出现的原因进行分解，当我们面临故障解决故障的时候就可以进行快速导航定位到根本原因所在，从而快速解决问题，我觉得在数据的问题解决过程中可以更加广泛到各个层面。比如说，我们在经常维护过程中会出现问题，用户说数据库响应很缓慢，是因为资源的缺乏还是因为应用上的问题，资源的缺乏是因为IO缓慢还是CPU短缺，如果是应用的问题是因为SQL的问题，或者数据库BUG等层面的问题。通过将数据库分析法引入到日常工作可以极大的帮助我们快速解决问题，并且可以屏蔽故障点，保持数据库持续稳定运行，这是我在工作中总结出的一点经验，谢谢！

罗老师：你刚刚讲的这种故障分析方法是理论探讨和实际工作中的总结，利用你的想法和实际工作经验中有没有利用他得到一些结果分析出来一些什么问题等等实例的方法和实例的印证说明它。

盖国强：我可以介绍一下，因为我在工作中一直遵循种种方法，最初是不自主的运用这种方法。举个例子，在联通的项目中可能会出现用户的故障树，我上到这个系统中首先会查看CPU资源是否十分紧张，接下来看CPU的紧张是由什么引起的，查看进程，一般有两种情况，一种是进程异常，大概占用50-80%，第二是大量进程累计。那么我们在这个项目中发现进程累计，我们发现这个SQL没有创建合理的索引，这时候找到这个问题的根本原因，这时候观察数据库它的压力马上就环节下来了，最后就得到解决了，特别是像这些应用实时性要求非常高，要求解决速度非常高，如果超过5分钟就视为是一次严重的故障，通过这种方法我都可以快速的解决这类问题。

唐老师：你说你所在单位是在华友公司，和下面提的是某公司是一回事吗？

盖国强：是一回事。

唐老师：你说管理全国30多个数据库系统是什么概念？

盖国强：在系统构建之初可能由于规划存在一些问题，在最初可能都会构建不的平台，现在就开始集中，集中到几个分省的节点或者总部的节点，到现在为止一些节点都是完成了的。唐老师：你说是为你的企业服务，30多个是你们提供服务吗？

盖国强：是。

唐老师：能否说一下系统调优方面的经验？

盖国强：实际上可以从两个方面来说。第一，当我们的数据库出现故障的时候，比如说刚才提到的例子，通常应用在测试过程中压力不大的情况不会体现出性能的问题，但上升到生产的规模中，高并发、高请求可能就会出现性能问题。故障出现的时时候我们也要解决实时的问题，系统在日常稳定的过程中我也要主动发现问题，找到具有性能问题的SQL或者应用来进行调整。举个预防性的例子，我们的应用在为联通服务的过程中有这样一些案例，当系统在上线运行过程中可以通过ORACLE的手段，来找到这SQL，通过逻辑度曲线把顶级压力进行优化，这样的工作是特别常见的，特别是在一些测试环节中。通过我们的调整性能可以提高10几倍这样一个比率。

周老师：树形的办法好象是一种霉菌的办法，好象是有先后顺序的，而且不同的运行阶段有不同的变动，一般硬件基本上没什么问题，在你的经验当中这样一个有线顺序是怎样排的？

盖国强：传统上是事后分析方法，我们在实际过程中解决是自上而下在头脑中迅速判断应该到哪个分支上去，通过Server来进行判断，这样一个信息在传输可能是光速的。我之所以提出这种方法是因为通过这种方法新的工程师在脑海中可以建立这种方法，在脑海中有序可循，然后找到问题的核心本质所在。

主持人：下面有请第四位选手陈述。

王宏志：大家好！我今天主要跟大家分享的是我在开发两个XML数据库系统，和基于XML数据集中方面的经验和体会，首先我第一个要说的是我的基于Ntl（音译）的存储，基本思想就是进行一下Doskloson（音译），在上面我们可以进行上下的搜索，这个系统还支持一些新型的草比如说VEfis（音译），我们还定义了一个代价模型，基于代价模型可以进行很好的操作。这个效率是非常高，但是它也有不足之处，就是安全性、并发性不是很好，在实际使用中更多适合研究型的，对应用我们就开发记忆数据库的XML数据库系统，我们通过一种算法进行翻译，翻译成SQL，虽然这个系统安全性有Server SQL来保证，我们在这方面也做了大量的实验。再比如说分布的集成系统基于XML信息集成系统，在这个系统中我们采取了纯VTO（音译，两个效率每一个差距都要到各个数据源中找，另外是数据仓库的，我们相当于进行了一个综合，有一个数据综合又有上一层机制，对于更新不是很频繁的数据我们到数据仓库中去找，对于更新很频繁的数据源仍然是到Server，我们还引入了基于代价模型的查询模块，怎么样发出去，怎么样得到结果，使用户尽早看到查询结果，并且在查询树立的案例上我们定义了一种RP的语言。

罗老师：你做这个工作目标是做研究还是想做商品呢？第一个系统和第二个系统有什么关系？

王宏志：我做的NetXML数据库是一个研究模型，后两个是实实在在的系统，已经开发完了。

因为先开发的是第二个系统，后开发的是第一个系统，第二个系统确实是为应用幅度，第一个系统是做科研中的一些研究成果希望把它变成一种系统来开发的。

唐老师：你讲的相当于两个技术路线，现在IBM DB2版本A所有双内核集中，支持XML，你说的两条技术路线，希望从实用的产品角度你能谈谈自己的看法吗？

王宏志：我更倾向于关系，为什么呢？第一点数据库开发时间已经很长了，一系列的机制已经非常成熟了，这方面如果说很快应用的话我觉得要建立在关系上使用。第二要在底层做一些优化，并且关系数据库可以采取合理的PTson（音译）的方式，关系的XML仍然能够达到很高的效率。

周老师：你的XML方面做了研究开发而且用了，用了是因为你课题需要用的吗？

王宏志：课题里确实需要它来用，数据源数据是什么形式的都可以，通过RPO（音译） 转化成一种XML数据存储到我们的XML存储数据终。

周老师：你用来描述全局模式吗？

王宏志：我们用XML数据存储实际的数据。

主持人：现在请第五位选手做陈述。

冯昕：大家好！我是从96年开始接触数据库的，一开始做过开发，做过DBA，也做过产品的支持，现在带领团队做自己应用的产品。今天在这儿想跟大家一起谈一下在整个产品的周期中，数据工程师的数据库的脚色和所担负的责任是什么。以前做数据库遇到很糟糕的事情，一直都在扮演一种救火的人员，有人说我的机器慢的不行了，或者我的机器宕机了，我都得解决。我自己觉得我去考虑去设计表的时候只是去设计表，对事后维护不会做什么考虑，但对维护TEM的角度来说要做的事情是拿到数据库就是要把它维护起来，有问题要解决，解决的时候解决不了就要问开发人员，因为数据库的表要达上千个。下面从系统分析角度来讲，很多国内企业在开发这个应用的时候觉得系统分析是跟数据库人员没关系的，现在在这个项目中，就是在系统分析中已经把数据库人员拿进来，一个是做数据的生命期，如果是告警的数据要在数据库中保存多长时间，再就是数据库的性能问题，我认为数据库的形式问题是设计出来的，调优是无止境的，是满足客户的需求就是最好的。再来就是设计阶段，数据库人员要做什么呢？我们要设计这些表，一切来讲作为一个数据库小组没有办法把那么多数据管理起来，但是作为数据工程师要知道所有的表，得整理一下，我们现在做的是哪个模块的人员自己设计这些表和索引，我们得整理一下这个表是否设计的合理，是否能满足在以后需求，起到一个整理的作用，我们会在发现问题的时候就解决了，而不是在维护的时候发现然后解决。在COTO（音译）阶段，它的领域都是不一样的，对于数据库工程师我们知道我们要把握变量，对于一个骄傲的开发工程师没有这方面的经验，我们作为工程师要带领整个团队把有关跟数据库开发的东西讲清楚，另外要跟开发人员充分沟通，让他知道怎么才能写出高效的SQL语句，我们要培训开发人员，他们在他们的领域有很多的经验，但在我们的领域中没有，我觉得两者要做沟通。在维护阶段，一般来讲对系统的开发，开发和维护TEM是两拨人，怎样能把数据库开发的东西扭转的过程交给维护人员，让维护人员知道我的数据库中是什么表，可能会在维护过程中出现什么问题，我觉得这也是很重要的。再一个就是在维护阶段，很多情况下DBA，在数据库维护阶段我们也要遵循一些DSIES（音译），如果是最常见的大表，在设计的时候没有考虑到，也不是没有考虑到知道是个大表，在周期知道什么时候该转移出去，或者重建索引，不是作为在开发过程中的一个模块是因为DBA来做的，所以我认为这样是很大的问题。别人很少用数据库的时候做数据的转移，我觉得这块维护成本是很高的，我们做的系统有11个省部署，但是没有纤长的DBA，只有SA担任DBA的工作，数据库的分区表的创建和自动删除都是通过我们的模块来进行处理的。这样可以节省大量的成本。

罗老师：你的材料上写你现在摩托罗拉工作，你说了一些相关经验和具体问题，在这里面你认为你在摩托罗拉以及在其他公司工作管理上有什么差距？

冯昕：现在我在摩托罗拉做的一个系统是CDMA的网管系统，负责设计和D ES（音译）模块，包括数据库的备份恢复以及数据库内部的一些整理，我以前也在国内的一些企业做过，但我在国内的企业我有技术但不能得到发挥，在设计阶段没有人问我为什么要设计，我说我需要参与，别人说我需要参与，作为DBA你是没有必要参与的，怎么把我的产品交给我呢？

因为开发人员对D ES（音译）是不熟悉的，用户提了一个需求但不知道D ES（音译）来实现，可能开发了一些代码来做，所以我觉得这地方就是D ES（音译）的问题，现在摩托罗拉这边流程就很规范，我可以在其中提出自己的建议，在设计的其中可以发挥自己的作用。

唐老师：你把自己的需求弄清楚了，把实际阶段考虑好了，你主要重视前期的完善，然后节省后面的成本。在运行过程中整个企业的发展变化的因素是比较大的，希望在前期做的很完美是有难度的，后期带来的问题来看，带来各种各样的问题能否有些建议对前期的工作，不是一般提要求，而且应该怎样做，而在做中不管是技术上和管理上的措施，这方面能不能提些建议？你是否还有一些别的体会在技术上有些建议使得运行维护阶段的成本就少了？

冯昕：这个要说一下测试，我觉得测试做的在以前的公司里面做的不是很充分，我简单的做一些功能的测试，对D ES（音译）的测试做的比较少，摩托罗拉会模拟现有和五年的环境，把测试环境看几天，看一下两年之后和五年之后看什么样子，我就可以找到设计中有没有一些缺陷，在D ES（音译）的时候看一下SQL语句是否能够满足五年增长的性能需求。再一个阶段，在维护阶段，我们现在是每天有一个HAS CK（音译），每天都要保留一份，一年之后就会看到数据的增长情况，可以预测两年之后会有什么问题发生，做长期的监控。

周老师：刚才你谈到做DBA来说最好是在DZING（音译）每一个阶段都能够参与和理解，对后来的维护的时候可以实现高效率，我想这是一个理想的情况，但事实上不会是这样的，正好你要参加逻辑设计、概念设计，这个机会不是太多的，拿这个做一个模式不会这样的，一般DBA模式早就做好了，那个时期你该怎么来改进这个系统？

冯昕：已经有现有的系统了？

周老师 ：大部分是这样的情况，大多数都是系统都已经做好了，你该怎样来改进？

冯昕：我以前做过移动系统的BOSS优化，这个系统已经运行将近一年多了，对于有问题的数据库作为一个DBA首先要定位问题在哪，如果这个系统定位在应用系统没有使用变量引起SD区的混乱。高度负责人我这个系统的问题在哪，然后提交给开发人员怎样修复，但这个开发人员不认为是一个问题，我要确定是哪一行代码，应该改成什么样子，当然这不是所有的SQL都可以改的，需要一个有限级，先把最影响性能的SQL找出来，也可能5个、10个，其中一个SQL是动感地带查询的SQL语句，而且比较复杂，在之后工厂区中将近占5M的空间，当时对于开发人员来说不改SQL可以但必须把这一条SQL改掉，对于开发人员来说非常简单了，改完之后性能有很大的提高，这是一个工作的方法，就是说怎么跟开发人员做一个沟通，让开发人员意识到你这个问题影响到我数据库的性能。

主持人：三位老师还有没有问题，现在进行下面一个环节，有请王云老师上台进行我们互动讨论环节。

王云：刚才我觉得很有意思的，有种感觉我觉得自己应该退休了，在这个行业中做了很多年，听了各位选手说的觉得这个事情上还有很多可以做，你们讨论怎么把实际的问题解决，确实有一些理论性的知识业界有一些宝贵的经验，我觉得还可以在业界加以推动。找一个话题怎样使大家有一个共同切入点讨论呢？好几个话题都是绕着数据仓库的数据集成，尤其国内做大集中集成来讲，我们就这个题目做一个讨论吧。我们有海量的数据，当然指标有高有低，当我们数据量变的那么大的时候海量的数据到底用什么样的方法处理这样海量的数据呢？当然有些方法是逻辑的方法，怎么把逻辑上的方法做切分呢？我们说化整为零来处理，既然谈的是数据库工程师，在数据库上来讲对海量的数据又怎样来处理呢？海量的数据不仅是效能的问题其实还有数据量一旦变大或者变繁杂的时候大家知道管理是很重要的因素，因为处理很多的方式是管理，在数据仓库大型数据也好，数据细累计起来，一天没有那么大，但在时间上的累计就造成了另外一个海量数据。大家可以就海量数据来谈一下，不管是你的创新意见甚至有些数据库的技术，或者对将来的期盼也好，把这个话题限定在海量数据的对你们的感受和想法。

王宏志：我首先说对海量数据的技术首先说两点，我认为处理海量数据是比较有前途的技术，一个是运行数据库，我知道国内有很多在做，好象IBM也在做，ORACLE也在做，这一点像您说的怎样化整为零，怎么样集成，这个我认为也是很有前途的，因为可以通过不断加硬件来提高这个数据库的性能。另外，现在关注的并不太多我觉得是压缩数据库，因为压缩一方面数据库的瓶颈问题，我个人认为是在磁盘IO上，而不是在CPU的计算力上，这是我个人的理解。因为压缩不光是节省存储量的问题，我同样查一个表，如果查压缩这个表的话压缩少了一半存量就少了一半。在应用方面，因为现在海量数据是越来越多，我认为最可怕的海量数据不是人输进去的，人的力量总是有限的，人一辈子不停的输也输不了多少东西，可怕的是物理数据，比如传感器网络，数据是不断过来的，一个传感器不断的发数据，这样的数据我们怎样来处理，是不是都要存下来，或者厂商一条条扫描，这样的数据也非常多。更夸张的是做模拟试验的时候可能数据量就上T了，对这些我觉得还是滞后应用的，包括研究界和工业界提出更好的更新更好的方法来解决这些应用

王云：讲的确实非常好，其中你提到压缩的技术，不知道刚好是不是巧合和帮我们做广告，我们在DB2第9版本中就有压缩技术出来了，可以有80%的资料不需要，这是一个压缩的。你刚才谈的不仅是量的问题，其实海量数据量的问题最后造成我们没有办法拿我们要拿到的东西，所以它不仅解决了存储问题和效率问题。你说从时间上的海量数据是很可怕，我们说你要不断把这个数据提高额这个数据的内涵。这些方面在应用上要有这样的观念地怎样做快速的集成提升出来，人们怎样把旧的资料可以整理，然后把有用的技术再抓回来，其实有很多技术都可以谋和在一起的。

盖国强：王云老师刚才说的非常好，不管是实时和来量的数据也好，都是我们要发现有价值的数据，主要就是在海量的数据中找到有价值的，很重要的一点就是对数据的分析、抽取和二次使用。通过挖掘或者抽取来提供我们最有效分析汇总来提供业务方面的应用。另外，关于压缩技术，很多厂商都提供这种技术，不管是ORACLE和IBM，压缩和解压的过程中必定会消耗CPU资源，当然可以减少存储，实际上我们也尝试过一些硬件资源。对于海量存储，我想说IBM的数据库和使用的并行，有人也提到过他的并行是真正的分布式的，可以使用多个服务器多个CPU协同来完成分布式的技术，ORACLE也有这样的技术，叫RX（音译）技术，需要有一个共享的存储，通过多台主机来访问共享的设备来实现访问。这两者我认为是有本质的相同的，ORACLE是一个实时的应用。从我个人理解，应用是最主要的。另外从数据库技术本身来说通过压缩或者其他方面的技术也可以解决这样的一些问题。我所经历的也有通过硬件的层面解决的，这是我对海量数据的理解。

主持人：其他三位选手有没有发言的。

段云峰：刚才王老师提这个问题应该是全球面的问题，尤其在我们这种公司明显感觉海量信息的增长，尤其从用户这个角度讲发现数据是很大的财产。数据量逐渐的增加也是一个趋势，这也是将来研究的一个方向和点。在海量数据处理方面第一是体系架构方面，在座讨论产品层的多一些，但我认为第一要研究的是架构层。第二是特征，再来考虑应用。集中化应用都是我们看到的一个趋势，我们现在在做的工作应该说有利有弊，像我们集团化的公司计划中主要是让我的转控力更强。我们人为地阶段还处在集中化的过程，有可能在集中化的基础上进行有效的分散和分工。在数据库这块还是我自己的观点，尽可能的研究这个问题，现在还是关注数据库这一套问题，如果说数据库这方面还是应该有理论找到一些点。在数据积累过程中，我觉得管理问题及其突出，而且我们现在发现一个经验，细节数据及其重要，原来可能在做的过程中作很多人观念中说汇总数据也可以。像我们的案例一样，原来没有想象会膨胀的那么快。还有就是数据的原则问题，在这里面也是学术研究方面的价值。整个数据仓库这方面我觉得有几个点，目标是什么，成本是第一位的还是数据是第一位的，我觉得成本角度来讲也会很关心。在数据将来的发展上，我觉得很大的程度上需要加大数据库应用或者数据仓库应用的力度，为什么这么说呢？因为在国外有过数据挖掘的例子，在国内我们也试图找到这样的例子，我感觉到一点应用人才奇缺，就是又懂技术又懂业务。

王晓刚：我就自己的切身体会谈一下对海量数据处理的经验。我最深的一点体验就是再处理海量数据的时候，核心的问题就是要避免OTP（音译）来解决OTP（音译）的问题，我们在数据仓库中有很多冗余，在数据仓库中有可能提高数据的效率有可能进行快速的装载，在海量数据处理的时候有可能画一个大表，在这张大表中有很多小表，我觉得以后索引有可能失效，因为查询索引的时间会用掉很长时间，把它分成小表，会提升它的效率。

冯昕：从我做SPS（音译）的经验来谈一下，在西部的一个工商银行说要扩容，其中有一个业务要把操作人员每一项记录操作放在这个表里，但是他对这个表没有任何的操作，当时这个表说要达到2个亿，结合这个经验我们在应用设计阶段要考虑到海量数据的存储，对于每一个数据都会在一定时间内才有，超过这个期限在连接数值中就没用了。我觉得在应用开发中就应该考虑到海量数据问题。

主持人：感谢各位参赛选手，下面请罗老师进行本轮比赛的专家点评！

罗老师：谈谈感想，感觉这个小组内容很丰富，另外我们的思维还是很敏捷的，王云老师提出的问题可以及时、准确的结合经验理论回答，这也是个很不容易的事情和很好的收获。当然还提出了更深层次的问题，就是对人才的培养，即懂技术又懂业务，不容易。因为搞技术本身的人不愿意搞业务，现在要把技术和业务结合起来也是个很重要的研究题目，有的国外朋友告诉我们信息化高了以后就变纯粹变成搞技术的人了，连业务都忘记了，但怎样去研究业务去怎么处理的呢，都不知道了，这是我们在荷兰的一个学生告诉我们的。这个事情本身就是一个复杂的情况。另外在表达过程中我希望将来做这种讨论的时候表达的更准确会更好，做系统分析和做DBA也好我觉得表达很重要。我曾经说过要善于例如有限的时间来说服别人，要人家听懂，这是我的一些想法，谢谢大家！

主持人：谢谢罗老师，再次感谢上午的各位参赛老师和评委！

 

主持人：大家下好！“2006年中国首届杰出数据库工程师评选”终选第三场马上就要开始，我是中国计算机报张延君，向大家介绍一下第三场的专家评审团，第一位是乐嘉锦老师，第二位是施伯乐老师，第三位是唐世渭老师。选手有第一位张黎敏、第二位庞恒志、第三位冯春培、第四位王翔、第五位汪海。

张黎敏：因为我从事的项目是达梦系统，我现在主要讲达梦系统，如果要做一个更好的系统就必须重新设计，利用最先进的共聚合技术，这样才能把一个项目做好。就是要勇于抛弃已有的系统在新的技术长做重新设计新的项目。第二点，在项目设计的时候一定要把基础打好，比如说，内存的管理以及基本的数据管理，比如说链表的完善对将来的系统有非常大的好处，例如我现在做的查询优化模块，正是有了这么多很好的基础工具、模块所以使我得心应手。第二点就是一定要有模块支持才会对将来的时间有很大的帮助。第三，一定要有坚固的团队，如果这么大的系统引进新的成员要用很长时间来适应新的系统，等他上手的时候这个时间就会很长,所以稳定的团队至关重要。以上是我的三个经验，谢谢大家！

主持人：下面有请三位专家对一号选手进行提问。

乐嘉锦：参加达梦4和5，3以前做过吗？

张黎敏：：也做过。

乐嘉锦：一共延续了多长时间？

张黎敏：：从98年到现在。

乐嘉锦：团队稳定性是个非常重要的体会，你这个团队的核心人员动了多少？

张黎敏：：到现在没有动过。从DM4核心成员到现在一直没有动过。

乐嘉锦：查询部分是对ORACLE的7.3？

张黎敏：Server。因为流动人员是比较正常的，但是主要的不能动。

乐嘉锦：你现在讲是基于代价优化，还有什么其他的优化方法？试过吗？

张黎敏：以前是基于规则。基于规则不是很死板，很灵活。

乐嘉锦：做事物处理也是你们在做死锁是怎么做？

张黎敏：造成死锁的事物只是回滚当前语句。

乐嘉锦：没有做细致的？

张黎敏：也参照了当前的做法。

唐世渭：你有运行维护的经验没有？如果有的话你认为如何在应用方面的经验分过来对你做DBMS的事情有什么促进作用，如果没有如何使得这方面的弱点？同样使得对DBMS核心有一个比较好的状态？

张黎敏：应用的经验比较少，几乎一进去这个公司以后就一直在做核心的项目，我们设计的初衷就是符合ORACLE标准，因为公司还做一些其他应用的，也会提出来一些其他不符合标准的，比如说SServer来满足在希望系统上的应用移植到我们的系统上。

施伯乐：应用是很重要的，如果没有应用很难说好不好，回滚会很多，你们有没有考虑过这些

张黎敏：应该是这样理解这方面，一个应用系统如果死锁很多的话应该在应用设计方面做一些处理，这样可能会更好一点。

施伯乐：现在事务处理保证可串行化用什么方法？

张黎敏：我们用了封锁的方法。封锁在每一个隔离级都是不一样的。

施伯乐：怎样来保障呢？

张黎敏：比如说对表对于封锁。

施伯乐：不管怎样封锁不是按照，现在我们知道两代封锁肯定是可以保证，未两代就会出现非系统化。

张黎敏：如果封锁力度很大的话是可以保证可串行化的。但效率会很低，而且在应用中可串行化的事物相对来说比较少。

施伯乐：优化做了些什么呢？在查询优化方面。

张黎敏：现在主要做统计信息，然后根据统计信息计算预判结果的大小以及O的次数，主要是针对这两个计算它的代价，把最小的代价挑出来。

施伯乐：那你要做很多试验了？

张黎敏：对，没错。我现在是做了大致的原型出来，以后还要根据不同的测试来调试它，一直达到比较优化比较精确。

乐嘉锦：封锁颗粒多大？

张黎敏：有三种，第一是表，第二是页锁，第三是行锁。

乐嘉锦：行锁用的不多？

张黎敏：行锁用的比较多一点。

施伯乐：整个关系都封锁掉了？

张黎敏：共享锁。指的是排他锁吗？排他锁没有。

王翔：我是做数据库的，加入支持队列产品怎么支持数据库分布式？

张黎敏：我们现在目前只支持连接池，就是说你有很多用户来的话我们有连接池来处理，我们在连接的时候满足很多应用的需要。

王翔：就是一个并发性的问题？如果我取一片报文，要入库，假设失败的话，你们现在数据库产品是否支持这种交易，怎么实现？

张黎敏：我们目前没有支持这种分布式的应用。

主持人：下面有请二号选手做自我陈述。

庞恒志：各位评委各位同仁大家好！我是来自大连的庞恒志，我是99年毕业，现在我在大连的IBM公司做一个项目，我们的平讯是针对数据库工程师这个领域，我就个人的工作经验在企业处理方面提一下个人的几个观点。第一，在企业信息化处理得时候，现在我们很多的企业信息化系统在最底层的数据处理上需要推向持久化的平台，很多企业都是这样。推向持久化的平台除了跨平台跨操作系统数据访问接口之外，还提供数据统一的优化，除了这个之外有非常重要的作用，那就是构建起一个企业的促进模型，尤其是建立其一个企业的业务对象，我觉得一个企业的数据处理在最底层要有自己的业务对象。我接触到很多企业在做数据处理的时候都是今天上一个系统明天上一个系统，系统之间的偶合都是通过数据来做的。第二，关于分布式处理，现在市场上关于分布式的紧密移植性产品非常多，可以说主要的数据库产品DB2、ORACLE、微软等，他们都有自己分布式处理得技术，都提供了相关的方法，但是现在市场上非常缺的是一种什么样的产品呢？随着网络的发展，尤其是移动数据库的出现很多应用都需要生产移植性系统。现在主要是跨平台有很大提升性能就在灵活性上，还有基于二次开发的支持，我觉得做的都相对比较少。第三，企业信息化数据访问的效率是非常重要的，我想简单的说一下关于数据库的优化。总的来说我觉得对于数据库优化不管是什么样的数据库产品主要是最顶层硬件和操作系统的优化，再下来就是数据库级别的优化，最后的一个层次是关于应用的优化。

主持人：下面请各位专家对第二位选手进行提问。

施伯乐：在看你这个材料的时候，有大部分数字，但材料中归纳成功与失败的经验的地方，第七条好象都是关于复制的。第二点你的经验分布式数据的复制，这里面也提到做了通用的访问接口，这个是怎样来实现多分布式的复制？这是第一个问题。第二个问题，你还了数据库关键很重要的是提供系统的高效灵活和可扩展性，你怎样做到这两条？

庞恒志：我们用了大量的技术，我们研究了很多目前的系统，最初是一个系统一个系统做的，最后把这些系统合并起来，并且支持这些扩展性，接口在定义完之后在具体的实现上使用的方法是不一样的，用户可以通过微软的形式直接传输数据。还有就是针对不同访问的时候，具体会根据传入的方式构建不同的方案。

施伯乐：中间用了什么技术？

庞恒志：在实现上用到了MQ。

施伯乐：不是说通用吗？

庞恒志：接口是通用的，从用户来说不需要看决策的细节。

乐嘉锦：里面提到区别灵活性、可扩展性，是怎么实现的？

庞恒志：在扩展的时候可以动态的加入模块，根据具体的情况构建自己的方法。第二个灵活性方面现在大部分产品都是支持配置的，我们的配置方面除了DB2还有IM文件配置方法，除了这个之外比较重要的一点我觉得在我们提供应用程序接口，我们提供了DBI（音译）。

乐嘉锦：应用程序和你的模式好象不一定能够完全放在一起说吧？因为你在上面写的是提供了即数据库设计又要提供系统的高效灵活，实际是怎样来体现的？

庞恒志：高效和灵活性，现在的这方面的产品非常多，首先我们要采用高效率的访问方式，访问的方式具体的细节就非常多，我们通过不同的接口去访问，比如说ORACLE是通过C接口来访问，我们曾经做过这方面的测试，有JAVA接口。从灵活性角度在设计的时候就考虑到配置可能是多方面的。

乐嘉锦：是否举一个例子说明对数据库性能调试方面的经验，你维护的哪一个数据库？这个数据库通过你调优的工作而使得它性能提高了，举一个具体的例子，因为你的材料面很广，就一个很具体的工作说一下。

庞恒志：我经常会收到一些关于应用程序访问数据库访问特别慢的情况，其中有的把系统发给我，说他一个系统运动要几个小时，我拿过来看，第一点先检查这个SQL，因为我们做了很多的连接，这个数据库产品是DB2，首先考虑到的是索引，DB2有自己的索引机制，然后要考虑的是什么呢？很多表的连接往往会形成两个表连接的形式，我们根据查询优化的原则把这种做大数据查询的优化尽量向查询末端推，再把数据合起来。除了这样的问题之外还有就是很多关于参数调整，比如排序的时候排出一堆查询不了了，在这个时候要对SQL的访问量进行评估。

主持人：下面有请第三位选手进行自由陈述。

冯春培：各位评审老师大家好，我是来自杭州的冯春培，我们是DBA，在我们公司DBA无基本上分了三个层面，第一是针对开发的，第二个层面是专门对线上系统做快速定位并解决问题。第三个层面就是对这两个层面技术指导，制订流程、规则，或者说在系统的架构上做些选择和判断。比如说今年的系统要是什么样的规模，在多少预算情况下满足多少需要，这是老板最关注的，这是我目前做的工作。遇到重大决策方面的话我要做把握，前段时间流行的关心理论说白了就是找出长度在6以内的人，当时的系统我们觉得是做不到的，当时我认为只能做到3或者4，作为对社会上的价值的话，比如说基于互联网把经验总结出来输入等，我也过这方面的工作，给他们提供支持和指导，具体在公司里面做这种系统的选型或者判断，我自己基于测试的模型和参考，一些网站有自己的方法，他们怎么做我们是不知道，那我们会采用一些模型，然后采用一些技术来实现得到自己的数据，然后做出模型，评估完这个厂商然后采购系统，这套模型我逐步修整，在大量应用事实反映情况下我觉得越来越有信心。因为这方面我比较了解，要扩展到把这套模型推行到其他朋友或者公司里应用还要做一个标准化的转化，这是需要大量数据来验证，必须要熟悉应用了解规模。这在我们公司是可以道德，毕竟我是替公司做的。因为我是搞ORACLE的，对ORACLE的细节东西是比较了解的，基于大量的应用经验和对数据库的了解公司才能放心让我们做这样的据测，谢谢！

乐嘉锦：材料我预先看过了，觉得确实蛮有经验的，应该是国内的高手。我这边想提个问题，一个是对ITPER（音译）的贡献在哪里？第二我觉得你在S（音译）方面是有很多方法，你是用了怎样的创新方法？自己的创新点在哪里？

冯春培：第一个问题，ITPER大概是2001年9月份成立的，因为我习惯跟大家交流，在交流的过程中自己也得到了提升，我觉得跟大家交流经验是很好的感觉，那个时候很痴迷这类东西，自己得到了很快的提升，作这个圈子中的朋友基本上都认识，这也依赖于ITPER给我们提供这样的一个平台，我们业带来了这个圈子中的朋友成长其实这是个良性的循环，有这样一个很好的场所我觉得是对我们的行业大大的促进了，如果没有这样的平台如果大家单枪匹马的话我想这个行业不可能成长的那么快。另外您说到SQL这样一个东西，你说到创新，不存在技术上的创新，我们做应用的创新就是把一些存在的功能或者特点，即使没有看到别人这样过，但是能够结合本质实现你的目标，成本降低和各方面的降低我觉得也是一种创新。

乐嘉锦：我承认你创新了。

冯春培：我不是说我创新什么技术，EMC等也有一些相类似的产品，在网络系统上的在一个时间点把IO或者把那些快照，然后把这个快照保留下来，数据库ORACLE有一个物理的SNBAI（音译），我们的数据库可能很大，每天的变化量可能是不多的，每天做一个备份，相对于每天要备份1/7个全库，这对数据库的量需求是很大的，我的数据库可能运行了几年，每天可能只有20个G的变化量，我就只有140个G的空间，我就可以每天做一个备份点，更我们带来得好处就是任何人想要查询两、三天的数据只要打开一个实例就可以了，不需要像传统的恢复，尤其数据库比较大的情况下。我同时解决了这样的几个问题，成本也比较低。

唐世渭：我想问一下你受教育的背景，原来学过什么？你从简历里头强调的是在网络技术论坛上跟大家比较有兴趣研究得到的成长，能不能把你受教育的情况和大家一起研究成长情况提几条对数据库工程师的成长这方面的建议？

冯春培：我是本科毕业是在北京信息工程学院，这个学校在北京当然是个比较小的学校。我上学的时候那时候专业叫专业信息系统，说白了就是原来的MIS系统，计算机专业占一半左右，那个时候也学过计算机原理、算法和简单的一些东西，数据库也简单的学了一些理论，当然那个时候学习比较简单。毕业之后自己研究这些东西我会发现我比完全没有计算机的来搞这个有些地方比他们好一点，好在哪里呢？其实OS很多上面实现的也充分了利用了这个东西，没有学过计算机的人不会那样容易一开始理解这个东西，而数据库研究又是一个实践性很重的东西，没有原理能够抓到他信息原理的本质，我觉得学过计算机理论课程，尤其是算法，对计算机系统CPUIO硬件方面到底怎么运作，性能跟哪些东西相关，什么东西会影响它，在这个理论上不一定会非常清楚，在你学习的过程中就可能跟实际的经验突然会跟你原来的东西对上号了，经验和理论其实是交替上升的，有时候我经验积累到一定程度发现我的理论无力来支持了，光学理论不行，必须要理论和实践相辅相成逐步交替上升。

施伯乐：你说对理论方面，光学了些理论没什么用？你数据库里面的设计了什么？

冯春培：我先澄清我没有说学理论没有用，关于设计数据库，我考虑的目标首先要基于它的应用的性能，我要考虑这样设计是否能满足我性能的需要，同时带来的存储是多少，是否要冗余，冗余有时候需要跟性能是需要调和的。

施伯乐：性能有时候会考虑吧，你的工作我不否认你做的很好，但你一定要在理论上下些功夫，性能我不反对，对基本的东西也不能放掉，数据库都隐蔽掉了，看不到什么东西，你强调的设计多一点，你做了很多工作，但我觉得你这方面要有所提高。

冯春培：谢谢！

主持人：有请第四位选手陈述。

王翔：大家上午好！我每天上班的关心的只有三件事，一是让我的系统适应业务的变化，二是130个国家，170多个组织实现共联，如何把我们的系统做运维。今天我可以把最近一、两个月做的一些工作向各位领导做下汇报。首先在使用了XML数据库会更好的把实体完成规范化设计。这也更好的符合了以往需要的结构，其次如何利用XML数据库来完成SOA应用设计，以往强调的是怎样更好封层，但对于拥有30年经验的机构，海关是直接把应用以层分割，包括这么一个很好的服务，最后再通过服务注册器来完成设计。我们在这之间永乐很多自己的处理语言，我们可能不太用开发工具来实现，而是用自己的开发语言。

施伯乐：你不要说海关，你要说自己做什么？

王翔：就是我设计的，我自己设计了海关的查询语言，此外产品设计也是我自己设计的，在完成一个工程点的结构里面我们要突出什么呢？每一个工程点往往避免不了完成工程表达，这部分也是通过XML转化为表达式来实现的，因为海关的所有每一个业务都基本上组建化了，因为MSDL是XML的，每一个工作流也是XML的，因此只要建立一个XML数据库就可以完成整个数据库的设计了。这种设计有什么好处呢？我们把资料是保存WORD文档和电子表格中一些文件中的，我们把它保存为XML，在上面架构一个XBORO（音译），第一我认为在数据库的布局上不能盲目的大集中或者盲目的分布式，在人员任务上也需要不拘一格，在我任命岗位的时候有关存储和数据库是融合的，可以充分利用他们的成熟的交换、报表进一步节省成本。谢谢大家！

主持人：下面有请专家提问。

乐嘉锦：刚才介绍了XML数据库，XML数据库跟你以前的关系库怎样相连？第二个问题，你在做DXS，里面讲了自己开发了一套完全基于XML的查询语言，这套查询语言是用在哪一个XML上的？

王翔：第一个问题XML数据库对于海关来说是不急于某一个产品的，因为以往我们吃亏太多了。

乐嘉锦：保存在XML数据库里面还是保存关系性数据库里面的DXS里面的字段的地方呢？这是有不同的概念的。

王翔：以往我们使用支持XML的数据库。我们既有系统的，只要把数据拿过去升级就可以了。您的第二个问题是？

乐嘉锦：是怎样的一种语言？

王翔：在我担任高级构架师以后我们也在自己基于自己的XML的语言，我们只是提供一个简单解析引擎就可以了。

乐嘉锦：而且没有对一个具体的XML数据库？只是SServer里面大致都能读的通？是这样吗？

王翔：只是说我们开发了这种语言，因为这语言包括查询定义，还包括行业的，03年我们在进行了一些项目实施后也做了一些内置的引擎来使用。

唐世渭：海关的系统是完全海关完全是内部中心还是有合作伙伴？

王翔：原来我们是很微软公司开发的，他们撤走之后完全是我们的人。

唐世渭：你们这就是属于甲方了，不管是银行或者电信都是属于甲方的，在碰到大的工程都会跟乙方来合作的，如何体作为甲方所谓架构师如何跟乙方合作的时候能够起到你的作用，而且同时跟乙方需要在乙方的经验中进一步提高自己？

王翔：一点我认为首先要区分合作中谁是主谁是次的问题，我们把握的是业务，对于我们来说乙方首先要满足我们业务需求。第二，在技术上我们是客、他们是主，我们经历了大约五年的时间完全把这个过程翻过来了，现在完全是由自己的人来做。

施伯乐：你用了XML类型的数据库系统，我觉得你没有说清楚，这是你开发的还是怎样？目前还在做这方面的研究，这不是做检测的问题，还在发展还在成熟。

王翔：因为我们的OA系统需要面向12个部委和组织，包括OA的文档流程，每个流程中进行的检查和每一点的执行功能天天念，在OA里要体现这个，刚才说了我们的业务流程是以XML的形式保存在数据库里面的，我们每一步的业务过程是通过组建方式来保存或者组建下来的，规则职能也是不确定的，因此我们的更新和维护只是改数据库的字段，而不是改算法，再一个XML数据库上进行业务修改和完善。

主持人：下面有请第五位选手陈述。

汪海：大家好！我是淘宝网的汪海，大概在04年初我们网站的业务发展的比较快，原来基于LinuxServer负载已经非常大，CPU和内存不可扩展性负载，那时候负载在10左右，这时候想到运行服务器横向扩展来进行，拿DELL的机器做RCC，还有HP的单节点服务器进行性能对比，这时候我们的测试部门说会涉及测试用力，跑我们网站测数据库性能，最后测出来基于Linux的Server，最后我们得出这个是响应时间最短的，我们就采用了这套方面。下一步准备迁移方案，因为原来单节点数据库在运行，我们需要在极短的时间内做到迁移，我们用到了ORACLE，在真正切换的时候只需要最后一点没有刷新的数据刷一下，直接提供服务，这个项目实现完毕后，客户方面就要觉得响应时间得到了明显的改善，我们也看到了LinuxServer的负载从10降到了0.5左右，这整个方案都是我们公司内部的构架师、工程师构建的，在当时这个方案是比较领先的我也ORACLE最早的一批用户，在这个项目中我们建立了升级体系从最初锁定当前系统的瓶颈到测试、选型到最后实施的一系列过程都是有公司内部IT人员负责完成的，在我们实现这个项目以后企业的业务更加发展了，ORACLEIIC的性能更加体现出来了，也产生了一些问题，到最后我们还是业务发展非常大的情况下最后还是回单节点的服务器。

乐嘉锦：第一个就是试了一下从单节点到RK（音译），又从RK（音译）回到单节点？

汪海：RK用了一年多。一般厂商说起来都会说扩到多少个节点，但实际上使用中很多东西都需要消耗资源，所以扩展形式并不是十分好，比如多个节点同时访问一个数据，传来传去会消耗很多资源。

乐嘉锦：最主要还是单点故障。

汪海：我们会用其他方法来解决单点故障，我们用了我们ORACLEIIC。因为我们是私营企业所以成本比较重要，当时没有采用小型机也是为了节省成本。

乐嘉锦：在内存里面直接交换性能会提高很多，里面有很多BUG也是确实存在的我们也碰到过。你刚才介绍了物化视图，本身是没有固定时间的，是数据库变化的？

汪海：当然有固定的时间了，但是我们会用JUP（音译）看出情况对它进行微调。

唐世渭：你在材料中提到过关于容灾和数据库，现在实际上容灾备份大家都很关心，在这方面能否简要从利用这方面过程中谈一下主要经验和教训谈一下。

汪海：我们是私营企业比较注重成本，我们把容灾定为三级，第一级是保证数据不丢，第二在数据不丢的基础上保证一部分数据，第三就是保证数据全部不丢，同时提供服务。我们实现最初级的方案用ORACLE的SLB（音译）技术，根据主库生产到容灾的数据库，容灾的数据库一直处于恢复过程中，但这一级容载不可能涉及到设备的切换，那么这个成本比较大，我们做的是第一个发展阶段。

唐世渭：这些灾点和容灾数据库发挥作用了吗？

汪海：因为没有碰到灾难，如果真的发生灾难我们起码还有一份数据在那里。

唐世渭：是在同一个城市吧？

汪海：是的，但区域相隔很远。

唐世渭：地震就很麻烦了。

汪海：地震我们也会提供磁带备份。

施伯乐：物化视图有没有修改？

汪海：物化视图是不允许修改的。

施伯乐：主要是提高速度？

汪海：那时候主要是提高切换速度，要从当前库的数据切换到另一套数据库中去，如果选择一个停机时间把当前数据库应用全部切掉，再把这部分所有表的数据全部插入到那个数据库，折算的话终端的时间会非常多，所以我们用物化视图在平时系统运行中一直把这个数据运行到运行库。

施伯乐：这个不能说是物化视图，不是一般的物化视图？

汪海：就是为了同步去做的。

主持人：下面进行互动环节，有请特约主持人王小虎老师。

王小虎：不敢称呼为老师，在座有三位专家在座，很荣幸到这个地方来参加本次活动，希望有一个问题请各位参赛选手讨论一下，关于SOA大家听到可能都是从业务层面，我们怎么去更好设计我们的应用系统支持我们的业务？从运行服务器中讲，怎样做模块化的划分用服务来提供？数据库如何能够更好提供服务的角度为应用所用？请各位根据自己工作经验来进行思考回答这个问题，谢谢！

冯春培：因为SOA这个概念在我们公司，我们公司有一个叫研究院的部门，主要研究整个架构。我们自己的部门是怎样给应用服务，IT系统、生产系统、CRM系统，刚才您提到的这些东西，前段时间像ORACLE也在向我们推销，IBM也在给我们公司做这样的东西，关于数据流这块，像ORACLE的产品其实它也没有什么特别的东西，ORACLE自己无非就是用一些接口，就是跟通常应用来说就是量数据库，要不全部刷看看根据字段变化把数据拿过来，ORACLE我们觉得如果数据变化量比较少的情况下可能会满足需求。如果数据量很多的话我认为做数据流是不能够满足需求的。IBM给我们做，这方面我了解不多，他们大体上可能用IBM的Q这些东西做数据的同步，我们自己的应用系统数据六有杭州跟美国之间，数据也是双向的，实施性可能在十分钟级别，因为到现在还没有一个专线，也是基于成本上的考虑，我们会把数据抽取下来以自己的模式压缩，自己做的一套数据流使得中国的客户访问杭州的数据，数据可以流到美国，国外的客户主要以美国为准，做数据流这块我觉得跟SOA数据流向有点类型。

王小虎：因为我们在谈服务，我提供给你可以重复使用的一些东西，从数据角度，现在数据不完全是数据库的概念，只要是一种信息提供给对方，对方可以用很表针的方式获得。我希望探讨的是当我们做数据库从业人员数据库可以做什么？

汪海：如果所有数据库请求都在道路数据库显然对数据库的压力相当大，我们第一层是由S（音译）来完成，第二层是KS（音译）是我们公司一个的社区开发的，数据库经过前两层过滤数据库这边的压力会很小，基本上很多用户的请求基本上在上两层就解决掉了，就是在这两层保持好数据交换就行了。

王翔：在SOA屋里面首先是一个软件设计设想，通过SOA把一些以往应用做部门服务，通过服务可以完成什么呢？完成以往同步的数据服务，也可以完成以往异构的数据服务，数据的价值不是说元数据就好了，是在于模式的转换。此外通过SOA可以完成以往跨部门的畸重举个例子，各系统平台是完全不同的，只需要通过各系统完成服务，在拼凑可以完成各系统之间的树结构。在我们海关看来，这是我的意见，在业务流程本身和业务的异常完全可以看作是一种数据来使用，现在在SOA中只有一个销售通道。因此，如果有这种想法的话整个应用的设计就会变得十分简单。数据不仅仅是业务数据，因为里面还有大量部门是做运维的，运维部门大部分关心注册表，因此我们的业务要不拘一格，技术层数往往保存于层次性能，使用与以往的层面就不太方便了。

庞恒志：我结合我们现在做的项目谈一谈对SOA的理解，GDR（音译）项目基本上是采用SOA，这主要表现在两方面。第一个方面我们有很多数据字点击比如说不同国家的税率是不一样，还有不同国家对系统的要求是不一样的，需要的配置非常多，现在我们维护的大概有160个左右，有一半左右是500强企业。后台的配置在架构上对一个应用程序上满足不同客户的业务需求可以动态配置一些信息。第二在信息的把握程度上来讲，可以把数据请求的形式碰撞到一起，前台的请求每次可以把它做到固定的数据结构里面，这是一个比较复杂的数据结构，在前台都是做一个数据包，后台根据符号的不同请求不同的服务，再传到前台，前台再根据这个服务解释成他要做的处理，这对于前、后台数据处理的模块化和可扩展性两方面都是非常有利的。再说一下我们在数据库方面能做的工作，由于引用了SOA我们在数据库的设计上就做了一些权衡，数据库的变化性是比较大，但是在结构上又是相同的，这样我们就可以设计出一些通用数据的数据表、视图等，方便了SOA这种服务队数据的处理和请求，但是在完整性方面和相关数据都会有一定的问题，我们在实现的时候就用了很多优化存储过程，满足面向服务的应用，在数据库方面还要要做改进。这是我的一些想法。

张黎敏：我现在想从数据库以及从软件的角度看待这个问题，很简单在我们看待数据库完成的事情就是说把用户的SQL语句解析出来，能够最快最有效的把信息反馈给客户，如果不能在应用层解决的话我们就需要考虑是否关系型数据库支持这个技术，如果不能支持的话是否考虑关系型数据库做些升级，如果能够满足的话我们会想在中间层做一些额外的转换来满足要求。

王小虎：非常感谢各位选手的回答！

主持人：各位专家还有什么补充的吗？我们的互动时间到这里，请一位专家对本组活动进行点评。

施伯乐：今天参加这个会因为从90名到这些人，我觉得是不错的，各个选手有不同的情况，有的是对DBMA做了一些工作，有的对应用做了些工作。运用现有的技术解决现有的问题，这是很重要的，总结起来各方面做的是不错的。但是如果有更高一层要求的话，我希望对你们搞系统和应用的人应该把眼里的东西提高一点，什么东西需要往上拔，这不是科学家的态度，也不是做工程的态度。我们的工作还要实事求是，做到什么地方提到什么地方，要提高的话进一步看一看你们提高的对不对。这是第一个想法。第二个想法搞DBM的确做了大量的工作，每一个技术都有两年新，过了这边另一面过不到了，要说清楚这个基础对哪些是好的，哪些是不够的。这样我想对我们整个数据库发展有好处，我就谈这些，谢谢！

主持人：非常感谢特约主持人王小虎老师和专家以及五位选手，第三场到此结束，请大家稍事休息。

 

主持人：第四场选手到场的有四位，第一位选手是朱健彦，第二位选手是齐红胤，第三位选手是董国兴，第四位王忠海。由于第五位选手由于特殊原因没有到达现场，将以视频形式跟大家交流。

朱健彦：大家好，我是朱健彦，来自苏州电信，我在苏州电信主要负责内网和外网开发，具体主要对数据库方面，原来我们是不做优化的，如果发现慢了就会更换服务器。主要是以信息中心为架构，包括20、30个系统所有这些都是在一个数据上进行反映，其他系统数据库，包括工程系统、智能网平台上的，主要是用SQL Server形式表达出来，以前用信息网平台上表现出来，如果都是用DPN方式来做，原来有20多个包，这样对数据库的压力比较大，我们在这方面对数据库做了一些优化，我们用数据交换平台进行处理，针对统一数据表做一些来自哪个系统，我们有系统的ID，比如说他有一个工号、他的姓名和自己的权限，取得带宽的日期之类的，我们的信息网只对这个表进行操作，这样很大减轻了数据库的压力，原来通过DTS方式我们信息网打开原来要是需要15-20秒的时间，现在控制在5-10秒。关系型数据库除了基本的数据存放和基本的数据检索，因为信息网融合了大量的数据，要求对信息检索要求是非常高的，我们还希望做到对一些附件的检索，在这里分了两个步骤，对于发的一些信息是采用微软的全文检索，分了两台服务器来做，因为微软全文检索有个问题需要定时维护，为了正常生产和查询分开一方面做全文检索服务。

主持人：下面有十分钟评审老师和你对话的时间，包括其他选手也可以向我们的一号选手提问，有请评审专家对一号选手进行提问。

乐嘉锦：从你材料上看你们用的是SQL Server？

朱健彦：对。

乐嘉锦：然后用了ORACLE数据库？

朱健彦：现在应用开发是用的SQL Server，但网上营业厅用的是ORACLE数据库，需要每个月查询电话详单等，所以采用的是ORACLE数据库。

乐嘉锦：到底是熟悉SQL Server还是ORACLE？

朱健彦：SQL Server比较熟悉一点。

乐嘉锦：还有互联星空？

朱健彦：这是三种方案中选了一种。

乐嘉锦：这样堆在一起我们很难看的懂。还有内部信息网，这个数据量会有多大呢？

朱健彦：本身信息量不是很大，每天大概有一万左右。

乐嘉锦：这个难度应该不是太高吧？用的还是SQL Server？

朱健彦：对。

唐世渭：因为我看了对运行维护这方面工作做的比较多一些，整个新的数据库和开发，第一在这方面作为信息网这个项目以后有多大的分量，希望你能够描述一下这两者之间的关系，或者是你在你的运行维护过程中如何来体会做数据库设计应该做什么？

朱健彦：维护后来发现了问题，我对SQL Server比较熟一点，所以主要由我来做。开发数据库都是由我来负责，包括设计建模，维护有专门人员。全部是由自己开发。

唐世渭：有用户给你们反馈信息吗？

朱健彦：上个月还有，我们现在用的是2005的主服务器和鉴证服务器，当时需要符合3A标准，具体要求是在灾难恢复上，我们模拟一台机器发现故障，用2005的技术大概是3秒钟时间就完成这个恢复了，但平时运用中大部分这个问题不会出现。

唐世渭：如何在维护反馈中得到这方面的建议来维护？

朱健彦：现在从设计上发现因为内部需求会比较多，有些系统可能纯粹的是为一个个人或者部门来做，从我设计的角度，我强调按照现有模型来做。

施伯乐：具体是怎么设计的？

朱健彦：主要是用POPRD（音译）来做。

施伯乐：规范的需求怎么样？

朱健彦：有的表我要取这个的工号和信息，有的时候可能关联4、5个表。

主持人：下面有请二号选手齐红胤进行三分钟的自我陈述，请抓紧时间。

齐红胤：各位老师、各位嘉宾大家好，我是齐红胤，从我个人经历来说我比较侧重于数据库的建模，可能在跟各位的侧重点有所不同。下面谈一下我在工作中两点的体会。第一，总的感觉数据仓库中数据移植问题是最关键的问题，尤其对大型企业来说全企业范围内的数据整合和数据一致性问题显得相当重要，对于乙方来说，半年、一年、两年总会结束的，但对于使用来说数据仓库是一个过程，对于企业新的业务系统随时可以建立，这些数据可以无缝的整合，所以对于我们这说数据架构师来说更要重视架构的灵活性和扩展性，这样会对数据的一致性打下一致性基础。第二，从实际工作中很多数据建模的问题，跟真正的技巧关系都不是特别大，更多的是对业务理解不深刻，或者业务变动导致建模问题，所以说对数据建模师来说要在工作中积累一些数据模型知识的经验积累是非常重要的。

乐嘉锦：怎样来理解数据仓库的主题重要？

齐红胤：对于一个大型企业来说应该有企业信息模型或者说企业数据模型，这样一般一个企业自己会分为20多主题或者几十个主题，企业信息模型如果划分好了主题也就划分好了，划分主题在数据仓库架构中也是非常重要的。

乐嘉锦：而且主题会变，今天分析这个问题要面向这个主题，明天分析另外一个主题完全会面向另外一个主题，这就面临第二个问题了，上面领导要让他做什么东西，主题一直是在变的，如果不变仓库应用价值就很低很低了。

齐红胤：对对，乐老师说的非常对。

唐世渭：你在自己从事的项目中你觉得哪个是有代表性的数据仓库的项目？

齐红胤：最近的项目其实相当于是在数据仓库之上建设的分析系统，对于数据的分析整合和处理反而略少一些。

唐世渭：因为你们是以乙方开发，数据仓库本身会有一些运行数据，你对这些数据以及其中的数据系统在缺乏了解的情况下如何使得模型和数据的对应任何解决？

齐红胤：首先要建立数据模型要建立数据模型的分析，相当于对企业原有系统的分析了解原有系统的结构，这就需要业务人员的支持。另外，对原有系统要做概况分析，这是相对来说比较小的数据操作系统。对一些大型的数据操作系统来说的话会提交给相应的业务系统来实现。

唐世渭：也就是你实际上是从上而下的，有概念模型和模式模型，在装载和映射的是 从下而上的，你如果对已有数据缺乏了解的话，你如何对待？

齐红胤：这个问题我觉得提的非常好，如果真的缺乏了解这个数据仓库是不会设计好的，第一是需要业务人员的支持，第二我刚才也说过需要行业经验的积累，对这个行业比较熟悉的话积累的知识比较多，对于常见的问题也就比较熟悉，这样会很好的。

主持人：感谢精彩的问答，下面其他选手有问题要问吗？如果没有的话请第三位选手董国兴的三分钟陈述。

董国兴：大家好！我是董国兴，下面就我的项目经验跟大家分享一下。第一是项目规划，第二业务经验，第三技术经验。针对企业全局管是比较大的，要跳出事件看事件，对每一步都要重复思考，为了解决这个问题我们可以引入项目管理体系，对各项工作进行细化，直到可以变成工作的工作流，在阶段工程中的数据传输和主机分配。第二方面业务经验，在这其中紧扣业务需求，因为现在政府正在该项服务转型，有很多业务面向公众，只要把握自己的业务系统才能不偏离目标，防止不理解业务系统造成对政府形象的影响。所以在法院和政府形象方面把数据复制融入到业务模型中去。第三方面技术经验，电子政务系统对工程师的响应能力和综合能力要求是比较高的，我们要提前预料到各种可能发生的突发事件，另外我认为主机和数据库是不分家的，在对充分了解数据库的情况下还要了解主机。在实践中有些工程师是对着配置手册，但一旦针对一些应用就很难解决，这是一个需要解决的问题。

乐嘉锦：在你的材料中看到你做的大项目比较多，在各方面工作中有很多经验以及体会。你做ORACLE性能调优做过很多，如果我给你一个ORACLE性能调优，你认为最大的问题是什么？

董国兴：首先是SQL，然后是应用系统的设计，还有软件的设计，软件设计是跟数据库系统的设计是同步的，第三才是硬件的设计。这些都完了以后在硬件资源以及这些都调好的情况下最后才是一些具体参数的调整。

乐嘉锦：做高级复制，SVS（音译）复制，SVS（音译）之间的复制和ORACLE都提供复制机制，他们之间的优劣在什么地方？

董国兴：我建议在网络不太好的情况下还是用SVS（音译）复制，如果网络好的情况下建议还是用ORACLE的复制。

唐世渭：主要你是做应用开发，后面的维护管吗？

董国兴：管。

唐世渭：作为你是不是两个也都管？

董国兴：作为我来说，我只是在开发阶段有些数据库方面的东西需要我来参与一些，但我只是后面的集成加运维这块。

唐世渭：你的运维经验能对设计者提出一些经验吗？

董国兴：可以提出一些SQL帮助一些方面的改进，拿ORACLE来说，有一些新的系统技术，比如说高级复制可以引进去，不一定通过查一个远程表来做。

施伯乐：你现在做了很多都是政务工程，数据库采用什么措施？

董国兴：主要是防火墙、入侵检测和防病毒的措施，在数据库方面会采用审计的功能。还有一点就是在数据库用户登录的时候会用一张表来回倒一下，我们在库里建了另外一套表。

施伯乐：我想这方面有很多工作，因为你们的指标很强的，一年下来在国外的话几千亿的钱都是通过人家把你的信息拿过去，几千亿的累计，我想这方面仅仅是这一点是不够的。

主持人：我看刚才三号选手在介绍的时候其他几位选手都很有思考的样子，若有所思，不知道有没有问题问三号选手？这可是一个很好的机会啊，几位评审老师都在场，后面交流也可以，下面四号选手王忠海进行陈述。

王忠海：大家下午好！我是王忠海，我的主题是良好的数据库结构性，按照普通的项目经验，调研结束之后系统的结构也应该设计完成了，但我建议公司花一定的时间分析一下库结构，公司接受了我的建议，又经过一段时间对数据库做了一些调整。一是根据旧的转换数据分析各种专有数据量找出重要业务表来重点设计，二是设计出可能用于数据交换和数据共享的表和视图。三是推敲一些易变字段的长度。比如说身份证号和信息编号。四是为了提高查询性我们设计了50多个冗余字段。五，在设计库结构的基础上，我们设计了一个非常详尽的结构，我们项目完成的相当顺利，并且得到了用户的广泛高度赞同。并且在多省份成功的推广应用，成为公司的主打产品之一，后来的事情充分的体现了调整库结构的重要性。一，是结构做了改变，但是库结构基本上没变。二，库结构用的是8.5版本。三，从2005年开始公安部门要求各系统的信息编号从原来的20位增加到23位，因为原来我们设计的是25位，所以说库结构也无法改变。四，近几年公安各个部门刑侦、海关都有信息共享的需求，为了打破信息孤岛，很多系统需要在刑侦系统中引用数据，我们很容易的就把信息共享的需求设计出来，并且因为设计的比较合理没有造成系统本身性能的下降。

乐嘉锦：数据库设计过程中库结构设计是非常关键的，要考验扩展性以后的延伸性，原来用20位而你提高到25位，而公安部到23位也依然好用。如果用20位你用25位是否浪费了资源？

王忠海：我们也不是说设计成5X4000，也不是这么设计的。

乐嘉锦：第二个问题，你设计了第一个项目是120张表，每一张表都符合第三泛式吗？

王忠海：对不起我的专业是学习无线电，数据库原理我懂不是很多。

乐嘉锦：数据库泛式模式是什么你不知道？

王忠海：我主要是从库结构这方面设计，我是根据业务的要求来设计表，因为我理论知识不是很多，但我是对数据库了解的比较多一些。

乐嘉锦：那你设计的是伊拉图（音译）了？

王忠海：我不是设计的伊拉图，因为分了很多部门的设计，是用主存的关系还是放在一张表中我考虑的比较多一些。

乐嘉锦：ORACLE数据库要你去优化，你的步骤是怎样的？

王忠海：从实际优化的经验来说，一般是我们的系统，如果是我们本身的系统，由于我们做了良好的优化，我们拿到一个新的系统的时候首先最简单的就是做SDOSKPAK（音译）的分析，然后根据ORACLE来分析可能存在的问题在哪里，如果全局都有这个问题可以先从网络上考虑，然后再从数据库操作系统本身考虑，我的习惯和前者不太一样，根据我的习惯是先去调整参数，因为我通常接触的是OFTP，所以说我习惯于调整参数，再去调整具体的SQL，如果说实际的参数没有调整先去调整SQL，发现不太合适再调整调整参数就会导致全盘改变。

唐世渭：我同意刚才乐老实说的你要提高数据库原理方面的知识，否则你根据用户需求，如果他有某一方面数据结合，对应有几张表，对这个问题你没有基本理论指导得话很可能你做出来的东西会存在问题。

王忠海：谢谢！

施伯乐：你有没有视图？

王忠海：有。

施伯乐：可不可以修改？

王忠海：不可以修改。

施伯乐：你唯一的缺点就是数据库规范都没有，我觉得你做的不少，实际做了很多工作的确很好，另外我还希望你提高一点，因为不同的规范有不同的问题。

王忠海：谢谢！

主持人：下面还有第五位来自上海的参赛选手胡晶玉，大家可以看到他在屏幕的左上角，请他发言。

胡晶玉：大家好，我叫胡晶玉，我是上海IBM的，主要负责软件售后服务没有办法来到现场，我主要在我的工作体会中做陈述。我认为在以往的情况中有一种重硬轻软的现象，很简单的问题就比如说当他们发现现在系统性能比较差的时候最先考虑的是先升级他的硬件而不是升级他的软件。第二点，目前硬件性能提升很快，但是因为很多人他们的理论还停留在几年前甚至十几年前的水平，可以说他们在做设计的时候还用原来的理论。现在CPU的速度和内存的速度很快，如果还停留在以前的理论就会对CPU产生一种浪费，大家知道内存的不足会造成CPU的资源浪费，那么我们就要考虑到系统的优化，为什么呢？因为有些时候在架构上设计是不需要考虑的，当遇到问题的时候损失是非常大的，怎么来解决这些问题呢？我觉得有三个方法可以来解决这些问题，第一现在各个厂家都可以体现自己专业的服务，我觉得购买专业软件服务是可以解决这些问题的。第二可以采用TCH（音译）的值，这些都是各个厂家根据他们的软件做出来的，实际上是有参考价值的。比如说各个厂家都做TOC，这样对我们系统的优化是很有好处，因为我们知道买一个东西知道它能够达到什么水平，那么就按照这个水平来完善系统。我的陈述就到这里

乐嘉锦：你是DB2工程师就DB2的索引机制，你比较习惯哪种机制？第二个问题DB2机制跟其他机制有什么不一样？

胡晶玉：第二个问题我听清了，第一个问题没有听清。DB2在管理是通过CM（音译）这个软件来实现的，DB2主要是关系型数据，另外我觉得在DB2里面还有一个特点，可能大家都不会去用，就是层次性的表。对于其他非结构化的数据，比如说MTM页面、图片数据是通过CM（音译）来是的。

乐嘉锦：DB2的索引机制有几种，你比较习惯于哪几种？

胡晶玉：我觉得你所讲的是机制索引吧？

乐嘉锦：是的。

胡晶玉：机制的索引我不是很清楚他还分什么类别。

唐世渭：你不是做售后支持吗？你从售后维护这个角度来看，使用DB2在做设计的时候应该注意哪些东西？

胡晶玉：有一点，很多客户还会用S（音译），它把某一个字符代表某一个含义，这样做查询的时候就会用S，这样就会为查询留下一个隐患，我们知道这种S很难利用索引，即使利用也需要特殊方法，另外还要了解数据库的了解，比如说做大型数据库的时候，在DB28里面索引都是是很高的。另外一定进行一个优化，以及内存IO都要进行考虑，内存主要是W2做初始化优势。

施伯乐 ：你里面写的通过新老保证数据库仓库的性能？

胡晶玉：我们可以通过新老两套系统来进行，我们可以保证我们有两套数据，当新的技术切实使用之后可以停止使用老的数据，使用新的数据，这样可以保证数据安全性。

施伯乐 ：我认为这不是数据安全性的问题，数据库的安全性是另外一个问题，这是实现的时候把数据得不对称的事情，这两个不一定一样。

胡晶玉：谢谢！

主持人：让我们以热烈的掌声感谢三位专家的精彩评审，下面进入我们下一个环节，有请特邀嘉宾王小虎进行下一个互动讨论阶段。

王小虎：实际上当我们建设一个应用和应用系统不是从白纸开始的，现在越来越多的应用可能需要访问其他的业务，遗留或者正在使用几十年的系统，包括政府和刚刚提到的刑侦综合业务系统或者一些新业务的开发，这时候可能碰到一个难题，系统的选型可能是不利于做出来的，当我在此技术上在做一个整合就会面临一个数据整合的问题，通过什么样的渠道可以访问原有的数据系统，方式有那些？哪些应用会更适合这方面的技术？

王忠海：我遇到的两个系统需要跟其他的系统交换，一个是刑侦系统和治安系统的交换，它的系统是治安方面最大的一个公司，刑侦方面需要从里面提一些人员的姓名、身份证和照片，他们的系统是具有权威性的，在中间用了中间层然后用MQ来传递，我们发了一个消息，接受以后返回一个数据信息，接收过来反馈给用户，这是一个。再有一个和治安的交换，他们需要从我们这儿提供数据，给他们提供XML的数据。还有一个是2004年的时候我们在做广西系统的一个项目时候他们以前是用SQL Server的，以前大概有100多万的数据，用将近一个月的时间把他的数据转换过来。

董国兴：我说一下，有几个系统，国外的，在01年做的时候尤其到了地、市级使用量不大，有SQL Server的，甚至XML也有，都是由当地来写数据程序，但公安系统都是MQ的传输，MQ对实时性不是特别高的，当时是WET网，通是没有问题的，从省到市再到区县就基本上网络条件不是特别好，所以说很多情况下都是再收集数据的时候到省一级，然后从省一级到库里面是用MQ的。从检查院是连接ORACLE的SQL Server，后来做国际性SQL Server的模型，这样避免了从底层的数据交换，避免了IBM所谓数据整合的方式。

齐红胤 ：我觉得对于遗留系统的整合最好的方式就是找一个做系统的人提供需求做数据的好处，这可能是最好的方式，如果找不到人就要找到数据字典，进行分析自己来导，这样的话我们可以在关系型数据库中直接导出文本，直接对文本进行加载，如果非关系型系统我觉得是比较麻烦一些。

王小虎：实际上在关系型数据库更多是针对ETL来进行。如果不同遗留系统会发现不一致的情况下你怎么解决？

齐红胤 ：说明要做的事情就是对企业各个数据系统进行分析，找出重复的部分，之后和业务人员以及和以前开发人员一起来确定找到概念上的主数据，从而做到真正的ETL工作。

朱健彦：如果一般符合一些标准的话，我建议你放在原来的库里增加几个表，试图用这种方式来实现，如果说异构的话就涉及到用XML的方式来导。还有一个问题，异构方式还有一个问题，升级还带来一个问题，原来数据库不用了还是继续用，又继续要用的话我想应该用中间件和文本方式，我们一般用的是文本方式。

王小虎：谢谢！如果我对原有系统不能修改或者无法修改如何获得数据？不知道在线上的胡晶玉听的到这个问题还是听不到。

胡晶玉：数据交换从实际上看有这样两种方式。第一，需要手工来做，也就是说不管是哪种数据库可以先不考虑数据库的种类，把数据导出来，比如说导成一种文本或者大家可以接受的格式，任何数据库可以接受导入的文本。另外可以利用数据库的功能，我们知道不管是DB2或者ORACLE都有复制的功能，可以按照复制的定义达到某些数据的交换。第三种方式可以通过利用各厂家的产品，比如IBM的II，这是专门用在集成不同数据库的工具，通过II可以集成关系型的数据库，也可以集成一些非关心型的数据，比如说IIC产品。

王小虎：非常感谢五位选手的回答，把时间交还给主持人。

主持人：下面的一个环节是有请我们的评审专家对此组进行点评。

施伯乐：我觉得五位选手都各有特色，有搞IBM系统的、还有搞技术和理论的，总的来说丰富多彩。我想数据仓库里面的问题可能有的要分清楚，要分清楚哪些是数据的问题哪些是数据仓库的问题，怎么整合。我想安全的问题还得考虑一下，希望应提高考虑一下安全问题。还有基本理论知识是需要的，为什么按有第三产值？因为发展太慢所以放弃。你不要说现在没有问题，将来出现问题怎么办？我想基本上的东西你们还是需要的。我就谈这点，谢谢大家！

主持人：非常感谢大家！下面我来宣布8月12日的评选到此结束，明天来由两场，感谢各位专家的参加，再见！

 

主持人：各位来宾大家上午好！欢迎大家再次光临“2006年中国首届杰出数据库工程师评选”的终选现场，我是中国计算机报的郭盈，下面介绍在现场的嘉宾，乐嘉锦老师、周立柱老师和周龙骧老师，一号选手王作敬、二号选手王明胜、三号选手牛新庄、四号选手甘荃、五号选手邹建，还有特邀嘉宾刘晶炜。

王作敬：大家好！关于数据中心建设的一些思想，由于数据中心建设是一个非常复杂的系统工程，而其中的一个矛盾就是长期的基础建设与短期见效矛盾的解决上，这个问题处理不好很容易造成整个系统出现问题甚至失败，本人认为虽然这不是1+1=2就简单而明确的问题，但是还有一些方法可以借鉴的，那就是整体规划分布实施。所谓整体规划就是把数据中心的建设基础打牢，我们通过建立公司的业务模型并使用数据建模工具来构筑整个公司的标准数据模型，在此基础上再构建面向各个主题的数据，按照我的经验，整个数据模型根据每个公司的不同，大致分为四个层面。所谓分布实施我认为当模型建好以后，既可按照轻重缓急分布立项来分布实施，华夏就是利用这种方式来组织实施的，实践证明效果也比较理想，以上就是在工作中的一些心得体会，请各位领导、专家指正，谢谢！

周立柱：你能简单的说说这些数据模型的差距吗？就像最高层，应用的是最高层，你说分了若干层，底下那层是什么，说说这两个层面有什么区别？

王作敬：最底下就是面向数据源的，是从原始数据抽取，下层是构建企业的标准数据层，这层主要是给业务处理不一致性规避，然后监理公司级的标准，在这个基础上建立数据级式，如果从标准层到数据级式层的环节多算法比较复杂的话，我建议倒是在这中间再建立一个ODS层，谢谢！ 标准层和基础层区别应该是面向业务的，而数据级式是面向主题的，对标准层实际有不同的说法，有的可能是面向级式的模式，我倒建议应该是一个ER模型，但对ODS这层来说根据实际情况不同可以结合SB模型和ER模型。

乐嘉锦：你在做ODS的时候不用ER模型吗？

王作敬：ODS模型是这样的，理论上说一般在数据仓库按存的数据仓库来说一般用FD（音译）比较多，但在实际的情况可能不是这样的，我们在华夏基金包括在现在的研究所FD是和ER模型相结合的，如果是一些力度比较低的，关于华夏的项目有这样一些情况，在标准层上建立的不完全是面向主题分析的应用，例如它的风险控制和审计这方面要求是对业务的力度进行分析，这样我们在实际工作中用FD模型不是特别合适。

乐嘉锦：我问的是不管是ODS层、数据级时层或者数据仓库层，概念不同得时候都是用ER模型吗？

王作敬：是这样的，只有级式用的是FD。

乐嘉锦：做级式的时候就不用ER模型啊？

王作敬：完全用的是ER模型。

周龙骧：看材料你是学数学专业，学完以后才进入这各行业，你觉得这样有什么优点？

王作敬：逻辑思维主要是比较严禁的，但有另外一个缺点，有点古板，我也感觉我的经验主要在这么多年的实际经验上，欠缺的是对计算机的基础功底比较弱，谢谢！

周立柱：你是学数学的，在数据分析上有过研究吗？

王作敬：对这个标准的建立肯定要进行业务分析，我们就是从业务分析开始的，然后构筑一步步建立标准层和数据级式。

主持人：好，那么其他选手有没有针对一号选手的问题？OK，下面请二号选手王明胜进行陈述。

王明胜：很荣幸能够参加本次终选，我讲的第一是数据仓库方面的，第二国产数据库，第三XML。 首先在数据仓库上我是华夏银行集中报表中来建设这个模型的，大家通常在做模型的时候就盲目去抽一堆数据要干什么干什么，在实际中往往会忽略一些东西，第一为什么要建，第二怎么建，第三为谁建。 我在学的时候纯粹是按照银行业务的需求来做这个事情，我的目的很明确，就是为了满足他的分析和报表，这是我为什么建的事情。 第二怎么建，我是按照模型驱动，根据业务模型来做，不能盲目抽一堆数据，一方面带来建设的成本，另外一方面对维护的成本也会相当高。 第三点，为谁建？首先我要找到业务群，我给你解决的问题也很具体，就是为了审计报表和结算报表。这是我对模型方面的一些体会。 国产数据库方面，我们也是首次做，目前我在金融里头用国产数据库大致有四个系统，一个是B2C，第二个有一个资源管理系统，第三个是ATM监控，第四个是移植报表数据已经完成。数据可以达到20个G，现在基本上运行的还算是比较好。 第三点，XML，主要针对非线程体系的要求，银行方面对银监会要报XML，这就涉及到数据库跟XML交互，在做这个项目之前相关成型的还没有，虽然IBM早期也推出一种XML的到处模式，但我们没有这个功能，我们在应用中来解决这个问题，我的阐陈就到这里。

主持人：谢谢二号选手的陈述，请评委老师进行提问。

周立柱：我看了你的简历是副总经理，领导啊？

王明胜：算吧。

周立柱：你还动手做事吗？

王明胜：做，一些关于安全的东西还是我来主持。

周立柱：同时你觉得在用国外数据库产品的时候觉得国内的数据库差别觉得还有哪些需要提高的地方？

王明胜：简单的做下对比，在开发中用国产数据库对我的开发量会带来一定的加大，再一个商用数据库提供的组件特别多，而且有些机制也比较完善，但用国产数据库我就会在应用当中消耗很多东西，就像在存储上同样的数据结构不能放在同一个表中，要隔成20、30个表来处理，这是从开发商来讲，从实用上来讲就是外部组件，尤其是面向管理人员操作人员不是像上数据库提供测试工具交互工具等。 国外的数据库普遍都支持存储设备，国产数据在这方面遇到一些问题，现在最新我们用的是北大（音译），以支持表空间了，这样可以化解我在存储上的问题。

周龙骧：刚才你说到很多数据模型，现实实践太复杂了所以用模型来描述，最直观的就是树型模型，后来出现了关系模型，就是把一些节点之间的联系去掉了，本来描述的很好的，为什么现在用关系模型来描述数？

王明胜：我认为关系模型对处理商用模式是比较好的，再处理一些商用逻辑大批量的查询的话，大数据量查询的话关系型数据库还是比较有实用性得。

周龙骧：可是ADSM到现在还在用，最主要的就是这些。

乐嘉锦：刚才你说做数据仓库的时候是靠模型驱动不是数据驱动，你这个模型跟主题有什么关系？

王明胜：我说的模型基本上就是应用模型，因为我在建的时候大致也分了几个层，首先就是原始数据，但有一点不同，我这儿有些存储是按单元存储的，也就是说对于数据来说我就是一个记录，然后在上层进行结构化，在结构化的过程中我根据它的业务模型或者业务需求来结构化我的数据，结构化完以后相当于一部分带有商用信息或者业务信息的数据了，在这个基础上构建他的模型，也可以用于直接展现。

乐嘉锦：不是先根据主题去建模型去找数据吗？

王明胜：对。

王明胜：比如说今年5月份报表要上了，我首先要分析有那些数据，然后先抽取再结构化。反正是根据他的业务需求走。

主持人：下面请三号选手牛新庄陈述。

牛新庄：大家早上好，我的专业是数据仓库和数据挖掘。在过去的几年由于运气比较好所以参与了国内的数据库性能讨论的一些项目，总的来说在这些项目中我个人有一些切身体会，想跟大家做下交流。 第一，数据库工程师应该应该有一个全面视野，数据库工程师要求就比较高，不光是具备数据库工程师本身的技术，还要把知识面拓展一下。 第二，我个人感觉到数据库工程师要加强理论的学习，现在走出社会以后自己过去在做的时候往往只停留在知道怎么做，但不知道为什么这样做，通过这几年做项目切实感觉到数据库工程师一定要加强理论和实践的结合。数据库工程师同时也要注意纵向和横向的联系，比如纵向关注某一个产品，比如关注DB2。 另外，我们在做的过程中，对一些起码的数据库的东西，就像数据库的设计，怎么根据它的数据类型来设计数据库索引，我们都应该注意，但国内很多时候重应用而忽视了数据库本身的东西，这也是我自己的切身体会。 第四，应该有一个很好的交流、够表达能力，有的时候可能要面向客户要理解他的需求，要面向你的团队能够做到很好的沟通与协调。 最后，非技术外的因素，我觉得数据库工作必须要有责任心，要踏实要谦虚，我记得2002刚出来的时候觉得自己过了几个认证水平就不得了了，现在想想真的是当时非常浅薄，我觉得数据库应该踏踏实实不断更新知识来迎合需求的变化。

周龙骧：刚才你说在应用中反而回过头来学习一些基础的东西，这一点我感觉到，你能举个例子吗？

牛新庄：比如要选择一个SQL语句，但一时不知道是怎么取的，现在在看SQL的时候就知道要看一系列做一些优化的分析等等，但这些东西在过去我们都不知道，但和书本上一对就知道原来这是这样。

周立柱：你现在的工作是独立咨询顾问，就是非常独立不依赖其他公司吗？

牛新庄：对。

周立柱：高科技个体户这个比方对不对？这个工作多少年了？

牛新庄：对。我2000年的时候接一些项目开始做，那个时候就开始了。

周立柱：这话你说起来长了，你早就开始干个体了，你在从事顾问的时候目前处理跟数据库大量相关的事情，在你认为这些事中跟数据库相关最重要的是什么？最重要的工作是什么？

牛新庄：我觉得最重要的是数据库的性能调优，还有就是安全。性能调优有类问题，比如说数据索引、SQL，大的项目都有这么几个共同的特性。

乐嘉锦：请你简单介绍一下性能调优一般采取的步骤。

牛新庄：我们一般做性能调优的时候有一个流程和方法，先从操作性这个层面上，举个例子从咨询平台上，我个人对性能理解无非对资源进行分布，逻辑资源部我们从操作开始入手，看看CPU是否存在瓶颈，假设有瓶颈就看是哪个部件有问题，假如发现是ORACLE出现问题，我们就改善ORACLE。假设这里存在一个SQL，咨询时间非常长，我们会看到这个优化做的不合理，然后调，调完以后看一下这个结果，总之就是一个缓和的过程，我们有这样一个整体处理思路，谢谢！

主持人：下面有请第四位选手甘荃进行个人陈述。

甘荃：大家好！我是中联集团的甘荃，我所做的事情主要有DB2、CSS、MQ以及ORACLE的产品，我所从事的项目主要是做银行核心系统，就是说在综合系统主要的功能主要是由OLTP的功能，有一部分叫做查询和打印的功能，OLTP的事物和查询的东西并存的时候会使得我的系统性能有很大的磁盘、IO、CPU会很忙，为了处理磁盘的性能以及CPU上的负载，我们使用了数据库的分离技术把数据库一分为二，也就是说把我的数据库上实现OLTP的事物，其他数据库去实现SQL的查询和打印功能。 我们目前实施的在江苏项目里面，江苏省农联社和陕西省农联社里面都已经使用了，目前正准备知识的有工商银行还有正在设计的，叫烟台商行的系统里面，也正准备使用数据库的分离技术，数据库分离的技术可以从几方面去做，有一种使用的是纯硬件技术，还有一种是使用纯软件技术，还有是手工去做。 其中第一种，比如使用了IBM的ESS的FLASH 拷贝（音译）的技术，比如DB2的复制技术。手工我们可以用备份源的思路来实现。

主持人：下面请评委老师对甘荃进行提问。

周立柱：你是技术总监，中联集团有多少人？

甘荃：700人吧。

周立柱：你做的工作跟江苏省都有关系，肯定公司在北京？

甘荃：对。

周立柱：我看你的材料中写了一切程序和脚本，这些都是你写的吗？

甘荃：对。

周立柱：作为技术总监你的责任一定是很全面的？

甘荃：我主要是负责客户第三方软件服务这块，做技术支持。

周立柱：一共有几个技术总监？

甘荃：有7、8个吧。

周立柱：你是唯一一个女的吧？

甘荃：有的，我们的总经理还是女的呢。

周立柱：怪不得呢。

周龙骧：你做得事情很多，但是你的表达能力还是有一点欠缺。你们现在在做技术支持，像有名的CRP软件，国际上有名的一些软件你们了解怎么样？

甘荃：我们主要是使用CSS、MQ、DB2、ORACLE这些产品，其他的产品接触的相对还是比较少。

周龙骧：你们的企业还不是很开放，好多事情都是自己封闭起来自己做，有效的东西如果用的很好的话一方面可以节省力量，另一方面可以和国际接轨，昨天有很多企业都提了这方面的希望。一方面要站在别人的肩膀上往上走，不是说什么事情都从头做起。

甘荃：是的

周龙骧：一个企业的力量还是有限的。现在国际上非常有名德国的SAP公司，你对他们有什么了解？

甘荃：这方面我了解的很少，可能我这个人做事情比较专业，其他外面的东西做的或者接触的比较少一点。

周龙骧：我觉得你们做企业应该有一个全新装置，以前唐院士是三峡工程的专家组组长，有一个工程系统没有一个公司接，还是国外公司接，如果这样做我们国家永远都起不来，如果都用外国人干是很不理想的。

甘荃：谢谢！

乐嘉锦：你的材料上也写了把一个数据库分拆成两个来用，实际上就是两个不同的系统了？

甘荃：我写的材料上是我在做的中游和黄的那个项目里面，有几个系统共用了，由同一个数据库做，系统会很忙，需要把一个数据库分离。今天我所说的是把数据库使用起来的一种思路，主库和存库是同步的一个和两个数据库的数据都是一样的，属于另外一种思路。

乐嘉锦：逻辑上是一个，数据同步就是应用对折这个数据来做的，逻辑上是一个吧？

甘荃：在物理上完全分开。

乐嘉锦：如果是两种完全是变成两个不同的系统了？

甘荃：把功能上分拆了，把应用的功能分离了，就使得我的数据库负载被分散了。目前使用的我觉得还是使用很多的。

乐嘉锦：我相信你这个系统肯定在运行了，只是分拆在做，是建设一个数据库或者两个数据库呢？

甘荃：实践起来我们分几种方式。第一种，我们一般使用叫做存储的技术，比如用IBM的FRS 拷贝（音译）的技术，用磁盘的技术实时写两份技术。还有从DB2的技术来实现，实时把主库的数据抽过去，还有就是手工移过去。

周立柱：我觉得你说的东西技术手段可以理解，你这么拆分以后原来的数据系统要不要变？

甘荃：不要变。我修改的地方还是有的，只是在客户端上指向的IP地址需要修改一下。

周立柱：牵扯到打开数据库，但数据库的数据都不要变？

甘荃：对。

周龙骧：相当于几份拷贝，这就会有一致性的问题，这两个拷贝是不是一致的？如果有修改的话这两个就会不一样了。

甘荃：我们不让它改只是运行、打印

主持人：谢谢甘荃！下面有请视频选手五号邹建陈述。

邹建：我叫邹建，做的是纯粹数据管理的工作，我今天谈的话题是结合自己实际工作过程中所做的事情。 在数据库方面我做管理工作不是非常完全的，包括对使用数据库人员的技术支持，这是第一点。第二点对数据库管理方面可以做到对数据库运行的监控，以及对数据库运行中产生各种信息的综合分析。而我们管理的数据库大概超过50台，包括开发环境在一起可以超过50台数据库。这些数据库人工完成的话会造成人力的消耗，然后质量难以保证，一般只是监控人员发现处理而已。而如果我们拿一个没有技术的人做那件事情的话可能会出现问题的时候没有办法及时解决。在这种情况下我们就必然需要一套系统来处理，但在数据库监控或者SQL的分析中要做分析的事情，比如对运行进行分析看看里面有没有错误，如果有错误的话要及时解决，监控运行时间是否超时。这些东西都是在每个程序上都有可能发生，我们的目的就是建立这样一套系统来完成，首先要对被监控的东西抽样出来，之后会发觉这些系统都有这样一个共同特色。 第一、我们是多台服务器，我们要对这些数据库需要获取我们需要的一些信息，还要把这些信息集中起来。 第二、我们要对集中的信息进行分析。 第三、我们期望的目标是通过系统自动完成的，因为我们会有一些经验。 第四、我们会建立一套知识库。 第五、我们在系统初步分析的时候会打开一份可以看到的报表给数据库工程师看从中解决问题。在获取信息问题之后通过系统自动进行分析，这样我们会发觉数据库的运行状态监控或者数据系统的分析都是在同一个框架运行的，这样我们可以完成建立这样一套系统来代替人工的目的，这样是通过系统来保障，不需要人为保障，不需要监控人员，同时因为有知识库的积累，对历史的经验可以积累下来，而不需要花太多的时间关注，从应用层次也节约了很多人力。 在我们公司已经建立这样一套系统，目前通过SAS（音译）来实现，通过VPN结合E（音译）来进行发邮件，会自动把邮件发到我们工作的邮件中。我的发言结束。

主持人：请评委老师对邹建进行提问。

周立柱：你现在做DBA做了一年，负责数据库是哪个单位建的数据库？

邹建：是我自己公司的。

周立柱：你的材料中提到15条跟DBA相关的职责，监控数据库的稳定情况，及时处理重大问题，在过去的一年里面碰到过这样的重大问题没有？如果碰到了你是怎么解决的。

邹建：因为在我这边严格说没有非常重大的事件出现，应该说最大的问题就是服务器宕机了才是最大的问题，因为我们有备用的服务器系统。到目前为止我工作一年还没有重大问题出现，有时候宕机了的话会利用美国那边的技术处理，对宕机的情况我们这边是没有办法处理的。

周龙骧：我的问题是你们建立的那套系统从头到尾都是自己建立的还是说利用一些现有的工具把它做出来？

邹建：目前是我们自己建立的。接下来可能我们会准备购买微软的MOM的系统，有的监控系统在短时间内是不会关闭的。

周龙骧：你的监控系统是在什么层次上面，比如说出现问题是给一个信号还是可以初步的处理一些事情？

邹建：对这套系统我们做了几方面的监控，第一是做长时间BLOK（音译）的监控，第二做磁盘空间的监控的等，这些都只是做通知不做处理。

乐嘉锦：做数据库的备份和恢复要自动化处理？你要用到工具，这个工具是你自己做的还是美国公司提供的？

邹建：监控这套工具是我做的。刚才我已经提到了我用的是ASS做的。

乐嘉锦：做自动化的工具代码要有多少行？

邹建：这个工具会包括两个部分，第一个部分是XIS（音译）包，第二个方面是数据库中的存储过程。大概用了XIS（音译）中的脚本组件，从被监控服务器到被监控服务器是通过组件改写的，这个代码行应该不超过200行代码行，存储过程的代码行就比较多，每个存储过程大概超过1000行的代码。

主持人：下面我们进入下一个环节，有请特邀嘉宾刘晶炜先生上台进行互动讨论。

刘晶炜：很高兴各位的陈述和回答，大家在数据库这个领域中应该有各自的专长，下面的讨论会关于提高的陈述和专业店展开，在座的五位至少有三位在数据仓库和数据分析领域比较广泛。 先从概念入手，您在自己过去经验中是如何认识什么是数据仓库，什么是数据级式？以及刚才你们提到的从构建这套系统里面业务需求的获取或者数据驱动数据实施方法论上面的异同点在哪里？

王明胜：我先说一下我的理解，数据仓库实际上是一种技术而不是一个产品，相当于把应用的业务需求以及我的数据库存储包括第三方的分析工具等等进行综合然后来为客户提供服务的应用模式。 对于级式的概念，我一直认为网上或者资料上没有明确的定义，通常都是通过业务的分层自己来定义可能这块数据是共用的，而且是一个指标，放到级式这一层可以公用，实际上是从应用分层的概念上做一个范围的划定。

王作敬：我认为数据级式BLP（音译）的一种技术，从数据仓库来看我认为是面向整个企业级的数据源或者基础数据，数据仓库是面向部门或者主题的级式。我还是觉得在构建级式上数据还是在它的准层上建立尽量适度的模式，我建议还是用ER模型来建。而级式上有它不同的特倒是用FD的方式比较好。另外，什么是最好的数据仓库呢？我个人觉得不是纯而又纯的数据仓库，而是满足企业需要的这样一套数据仓库就是一个最好的数据仓库，谢谢！

牛新庄：我对它的理解是，我认为数据仓库首先是有需求驱动的，确实产生大量的数据，怎么样能做一些更细的划分，像一些大银行的VOIP一些东西，首先他是有这方面的需求。在数据仓库中，我个人感觉一定要注意需求的理解、需求的驱动，还有需求的时效性，业务的正确性，第三点要在数据质量上得到一些重视，我个人感觉数据是最重要的。谢谢！

刘晶炜：我觉得各位的谈话有一点的启迪性，这里面你们谈话的ER模型，其实在数据库只要你用关系型数据库基本上地的都是ER模型，在这个行业中很多的准则，也经常探讨数据仓库级式里面SFS模型，你们提到一个关键的问题，数据库模型面向管理对象分析业务人员现在很多在用，怎么样让一个数据分析系统让它相对比较稳定，有没有层次，如果有层次他的层次应该怎样划分？

牛新庄：我个人感觉是这样的，因为很多时候需求是多变也是正常的。过去我们碰到这种情况，在构建模型的时候要找业务人员沟通，但是业务人员本身不懂技术，对需求的描述可能不是非常的详细，这种情况下可能造成按照他的需求报表，我个人倾向现在对各个行业我们能不能利用一些成熟的东西做一个相对稳定的信息模型，有的时候借助与这个环节对企业构建数据仓库会起到事半功倍的效果。如果让我们自己在企业内部搭建这种模型的话可能需要很长的周期性，而且也不能看到全局性。

王明胜 ：我改变从实际做系统的角度看层次这个问题，大致我现在分了三层到四层，第一层是业务数据包括手工录入的数据，比如散的数据信贷的数据要各方面共享就需要拆开存，业务需求的变化我怎么来做呢？要是的表也好，要求的指标也好，我都要求他们去定义，当然这种定义的标志语言现在没有规范，我自己定义一套，定义这个时候实际上完成了两个过程，一个是完成了加工过程，第二确定成型过程，再上面就是OLP的模型了，在这面我们COMW的数据。

王作敬：关于需求驱动我们在华夏的项目是采取几种方式的，一种是用调查问卷的方式，向业务部门进行调查，主要是建立企业业务模型，比如说从要素方面和产品方面向客户展开，让业务人员用通俗易懂的方式比较好的达到沟通。另外，我们在建立数据仓库的时候还是面向整个数据的层面，因为分析主要是三点。第一，现有的业务是怎样的。第二，因为是集成还要对现有的技术系统吃透。第三，还要对未来变化有前瞻性，这样做出具有前瞻性的分析报告。 从这个模型来看，至少要建立三层，原始映象层和标准层我觉得还是需要的，根据企业的情况不同，甚至可以达到业务的原子力度，存储的问题倒是一个问题，因为的企业数据量比较大，我建议根据实际情况分为两到三层的存储方式。主要业务比如对标准层来说可能放在更高级的存储上，可能用次一点的存储设备，最后比较长的存储数据可能利用磁带的方式进行存储。

刘晶炜：我们还可以讨论具有现实的意义，比如你今天做了华夏银行，如也许明天可以去中信银行，哪些东西可以被重用信息标准化在你们现有信息利用方面你们是怎么考虑的？

王明胜：对于我的经验来说希望信息层基本上不用动，我的数据不是在抽取中原封不动的拿过来，整个我的定义层包括表结构的定义都是我让他们来定制。最后一层KBO这层需要变，对于整个大架构动的不会太多。

牛新庄：根据我的经验逻辑的层面是不变的，可能在整个逻辑教研这个过程会保持不变。第二点，在建模这一层，刚才我强调一点，当初在构建数据仓库的过程中，你是面向行业还是面向特定的项目，我更倾向于如果有一个比较稳固的业务模型，这个业务模型的可扩展性就非常好，这样把它充分切换到中信银行的时候把应用模型做些改变，我认为有一个非常稳定的业务模型是非常重要的。从不同的角度、从客户这边、从开发商、从事实可能都有一定的要求，我还是认为在设计的早期多花一些时间，搭建比较健壮的模型是比较重要的。

王作敬：我觉得验证的方法应该是一致的，一般的企业都会有产品和手段，根据这个基础构建业务模型然后再构建数据模型，数据模型的建立对不同的银行要有一些调整，根据不同的企业可能不需要标准层直接需要ODS层在这个基础上再构筑数据级式，在我这个两个项目有两点的考虑。 这上面我构筑数据中心的应用不纯粹是面向在线分析OLP应用的，比如证券行业和金融行业在这个时候用OLP的应用是不合适的

周骧：刚才刘老师提到行业的问题，有各种银行，涉及到的术语应该考虑，还有框架和共用的东西，这些方面你们现在在应用当中是否都考虑了？

王明胜：共用的话通常上级机构这部分能共用，比如银监会，大额小额支付的，从我们开发商的角度来看，肯定在这方面也会考虑的比较多一点，因为一方面对我的软件生命周期来说是有好处的，另外对我二次建设的成本也会有所下降。 另外在选型方面，这么大的东西毕竟不可能自己完成，在选择产品上我会选择我集成的产品使它将来的变化力度也大一点，或者给我的支持力度也大一点。就像现在我支持的东西选择CK（音译）占用的领域比较大，为什么我们也采用了国产数据库呢？其实是想从头到尾尝试一下国产数据库。这么选择一个是对国内软件的支持也是一种呼吁。另一方面能在支持上和针对特殊行业的改变支持上能好一点，比如说很简单的，要求是ORACLE或者IBM，针对这个应用给我来个真正东西吧，他肯定不会给，我们选择国内的数据库是好，你给我做些优化改变是可以做到的，这是我在我建设中考虑的几个方面。

王作敬：关于架构的问题我觉得国内是一种趋势，在项目的建设中对不同的行业，按金融领域来说肯定有共性和不是共性的地方，在中心建设上面我们建设了除了业务应用之外还建立了两个平台，一个是管理平台另外一个是数据访问平台。管理平台主要进行一些管理、调度和认证，访问平台恩是有关数据中心建设是提供其他公司的数据源，主要提供数据访问和数据加强，在这个平台上统一完成了这样的功能，加强了这一层以后就屏蔽封装了后台的差异。 另外关于应用方面的考虑我们引进了基础平台建设的概念，也就是说我们讲基本的东西像应用的一些通讯、数据加密和认证，数据库我们做在基础层上做了封装，而在应用层上做了一个构建化的处理，形成业务构建，如果将来的业务发生变化可能只是对增加新的构建或修改原有的构建再通过基础架构平台完成通过对他的管理和调度来实现新的应用。

牛新庄：基本上在这个问题上的认识跟他们两个观点相同。

刘晶炜：现在针对甘荃来问一个问题，关于性能和数据库的效率，不光是在你们的系统，有的可能是交易性的负载，有的可能是查询类的负载，各自有限级也不一样，在这方面来说从你们来看从现在来看你过去用过什么技术，哪些技术是直接用数据库的技术？有什么优劣？

甘荃：我们会使用从数据库的配置上改一些东西，还要优化一些语句，还会对CPU及其他设备上解决问题，最后把它分离出去，我们主要是用这些思路来处理问题。

王明胜：我觉得在应用层面如果别出太大的问题还是能让开发商接受的，最主要的是你的IO、数据库磁盘一定要达到一个平衡。

邹建：我们会分两个层次来处理这个问题，原因已经出现了我们会采取一些方法，第一是对数据进行分区，是在表格级别上进行的。第二会采用数据库的复制技术，尽量把对同样的请求分散到不同的服务器上，通过复制技术把同样的数据库复制到多个服务器上去这样就可以分散压力。 在应用层面上，我们要适应这种数据库会采用这样的措施，我们会建立应用程序的配置文件，只能把这个应用程序应用到多少台服务器，哪台是主服务器，人们应用是什么样子的，那么我们会选择下一级存储来符合我的服务器。如果我配合的主服务器不同，当某些服务器宕掉了任何程序都不会受到影响。在应用程序上我们还会做对数据的缓存，可能要把我们处理得数据缓存在我们的应用程序上，通过定期的方式发送到服务器上去，在某个时间点不会对数据库造成压力，这样会在空闲的时间把信息分散到服务器上，既然考虑压力了，就要考虑压力是怎样出现的，是我们的应用不够还是我们的语句不够合理，或者是我们的处理方面不够合理。

牛新庄：我觉得应该从数据库的兼容性和可扩展性相结合，以后看有些人设计的表，首先要明白这个表是面向什么的，是OLTP的还是分析性还是混合型的，还要考虑存放的周期，在这个表上读写的情况我觉得都是应该注意到的，今天在存储上基本不用我们关注了，基本上都智能行乐，主要分析一下业务需求对应用有一个很好的结合。

主持人：由于时间的关系今天的讨论就先到这里，如果大家意犹未尽的话可以在会下继续进行讨论。下面请专家对本场做点评。

周立柱：我简单的做一下点评。我觉得今天上午这五位工程师给我们讲述他们的工作经验和报告，第一看出来他们都是有丰富的实践经验，有相当多的工作经历，而且是对当前应用中碰到的实际问题，他们是如何解决的为我们展示了，这是第一点。 第二，在讨论过程中可以看出他们非常自信，这个我们可以理解，因为他们是从这方面的工作中都是由自己解决的。 第三、对我们提出的问题基本上都有非常好的解答，在互动和解答过程中大家都可以看到。 建议有这么几个，第一在计算机科学和技术的大领域中新的概念不断出现，在数据库中就有很多，我觉得在陈述和讨论的过程中需要把一些基本概念搞清楚，比如说模型，最好说清楚你是在哪个层面的模型，比如ER模型，ER模型用来做逻辑设计时候来用，你到最底层的时候甚至可以只是一个文件系统。 另外出现一些新的技术，新技术希望大家在今后工作中了解到，尽管有些东西还在发展过程中，还没有成熟，可能你们已经接触到了，因为它肯定会成为未来数据交互的一个标准，比如同一个领域或者不同的领域中数据进行交换的模型是什么，实际上应该对这些浅显的问题有所学习。 另外应该把表述的能力提高上来，比如拆分，为什么要拆分，带来的技术是什么，好处是什么，拆分是有前提的，如果有大量变动拆分的方案就不可能了，讨论的时候一定要有前提说好了，第一要有问题，第二要有你的答案，最重要的第三要说清楚你问题的效果，你有问题有答案但效果说清楚没有，这是一定要重视。 一般来说我们在数据库领域有一个说法，基本上都说应用驱动，不大说模型驱动，因为模型驱动实际上还是从技术的家度讲。我觉得总的来说给我的印象很深，感觉非常高兴，特别是中国处在制约转型时期，IT要变成支柱产业，很高兴你们是这支队伍中的一员，我就说到这儿。

主持人：下面我宣布本次评选到此结束。

 

 

 

主持人：现在开始第六场评选，先介绍一下选手，一号选手是李强、二号选手丁思非、三号选手袁春光、四号选手常红平、五号选手钱彦云，五号选手是不能到现场的李强。下面有请一号选手李强进行三分钟陈述。

李强：大家好，我叫李强，来自深圳，很荣幸参加本次比赛，也很荣幸见到大师，也很高兴见到各位朋友，尤其是业内行业。 我是来自深圳，主要面向国外客户IT ServerS工作，我是在主机IBM一系列大型机，DB2 ZOS3.0和系统维护和性能调优工作。我从事的工作主要面对的客户是一些国外客户，包括欧洲主要是南欧还有德国和澳大利亚。具体面对的行业包括有银行、DSBK（音译）、通信企业包括澳大利亚的T（音译），这是澳大利亚的首屈一指的电信运营商。具体我主要是向国外大客户提供远程的系统支持和管理。在工作中我们除了经常用到基于DB2和主机系统一系列工具之外，另外在工作中要求都英文写作，因此我的参赛文档是用英文写作的，希望能够得到各位评委的理解。具体在DB2领域从事大约四年的时间，主要是从事系统级的工作，包括系统级的调优，还有包括数据库概念的物理化以及DB2 BUG的性能调整，还有对DB2本身版本的迁移，尤其主机DB2正面临从DB2 版本7升级版本8的工程。另外除了系统级的性能调整还有备份和恢复，这里包括CSTBCP（音译），尤其 是灾难备份和恢复。 另外我最近的一个项目是服务于澳大利亚的一家电信运营商，除了有应用程序的调整之外更多的还有系统的调整，有时候这个系统调整甚至包括DB2的范围了，我参加这次数据库工程师比赛可以对我来说感慨良多，因为这次比赛使我认识到在主机这块IBM数据产品发源地之外的天地，看到这么多专家在通用平台上的开发，很荣幸各位专家各位评委在这个地方向各位学习。 另外我从事的行业还是有一定代表性的，以IBM为例，现在我国正向从世界性的生产基地，正在专办成技术按的发源地，IBM就很明显把最大的IT ServerS（音译），把各种业务逐渐转到中国、印度、亚太具有成本较低的地方，在可以预见的将来，不知道大家了不了解，国内对大型机这方面的培训越来越多了，在国内越来越多高效有IBM大型机的实验室，所以我甚为在可预见的将来在大型机这块在系统管理这块应该在国内将迎来一个蓬勃发展的明天，我也希望在这方面我认为是颇有挑战性这方面的经验分享给大家。

周立柱：我问你一个技术问题，在你的材料中第三个项目中，你能不能具体说说它的难点你怎么解决？

李强：这种TOS（音译）最大的特点就是容量非常之高，一般是T级的容量，对于在这种处理上有些常用的观念就不太适用了，比如说为了保持数据库表的性能，为了保持它很好的查询效率，我们经常需要对这表进行数据整理顺序化，能够按照索引有序的序列来排列，我们一般对这方面的操作在生产上，如果一般的表空间需要一周至少做一次整理。但是对于这种很大很大的表，忘忘做整理就非常危险，因为数据量非常之大，这时候需要临时的存储空间，另外对你的CPU、内存、辅存、硬盘、各方面的要求都远远超过了一般我们规划时候的需求，所以我认为对它的难点就是说怎样能够避免整理操作避免对碎片的整理，同时又能保证有很好的访问效率，我认为解决这个问题的关键所在就是设计好索引，同时另外要设计好整理的物理属性。 首先说说索引，我们一般用分区表来实现，主要用一个K这个键值，就是到底哪个数据放在哪个分区上，制订这个K就很有讲究，以一个银行为例，银行有很多的连接交易，如果说是连接交易的表空间，我们建议以时间作为你的分区表的建立，这样随着时间的增长，你的记录是一条一条，你的分区就是一个分区一个分区有序的增长，这样在操作的时候就可以对个别的进行操作，这样就节约了操作所带来的消耗。 但如果是很大的系统，我见过德国一家世界知名的汽车厂商，他有员工几百万条记录，如果新员工他的ID总是逐渐往后的，因此表的记录也是逐渐增长的，这样的话基本可以保证增长是有序的，这样就不会出现过多碎片。

周龙骧：在你的陈述中提到对DB2的升级，DB2新的版本正在推，DB2 第9版，你怎么看？

李强：这个话题对我们做主机的是一个比较严峻的话题，现在来说甚至有的银行没有运用DB2，有的还在无用DB2的版本7，现在在国外很多银行也是升级到版本8，现在版本9现在只是出了BT（音译），而且还没有公布，我认为对我们做主机上的数据库来说，坦率的说我觉得这块的影响有待观察。因为，现在对于主机来说应用性或者兼容性各方面可能不是最重要的，最重要的是可恢复性和安全性。我现在没有看到使用DB2V9和进一步了解，但我所知道的各家银行仍停留在版本7，现在刚刚向版本8升级。

乐嘉锦：DB2中的缓存机制跟其他数据库的缓存既知又什么不一样？

李强：我认为是这样的，数据库除了DBP（音译）之外还有调法，首先是物理设计，要符合规定，比如说用DB2的BDP（音译）的首次分配有多大，根据我们的经验是首次分配是二次分配的1/4，怎么样选择你的索引，另外是否使用组合的索引，多列组合构筑索引也是一个考虑的范畴，因为多列组合的话从性能来看会更好的提高性能。

主持人：谢谢李强，下面有请第二位先手丁思非陈述。

丁思非：首先感谢各位专家和主办方给了我们这样一次机会，也通过本次机会给大家分享一下想法，作为年轻的工程师来怎么样成就自己的数据库数据呢？大家都想成为英雄，我觉得成为英雄需要向行业内的业务人员以及专家多请教一些对于业务的理解和业务的知识。历史的车轮告诉我们技术发展的原动力是不断发展业务需求，像在国外，IDC等一些咨询公司一直在引领着这个行业的方向，在中国刚刚起步，所以这也是我在咨询公司的一个很重要初衷。 第二个是扎实的技术，随着行业不断的细分，可能对于某一个人来说只有有限的时间关注某项数据库的产品和技术，作为我们来说应该多关注计算机行业内其他领域的知识，刚才看了上一场的发言，同行说到调整数据库怎么调整，其实并只是说关注数据库的方式才能调整数据库应用带来的性能，及时也要观察计算机行业的方方面面。就像我最近做的一个项目，事实上也没有什么太大的技术上的改革，只是现在做的联机分析数据库作为业务系统的数据库引擎，这样的话发挥了很好数据库的特点，并且解决了一些应用系统原来使用关系型数据库无法解决的问题。 第三，我觉得作为很多项目中有英雄也有宝剑。我们经常会遇到这样的问题，经常会做很多应用牵动已经固化的结构，这是为什么呢？有一个很流行的名词叫“软件工程”，刚才我也看了上一场的主题讲到有一个数据仓库是什么，我觉得数据仓库不光是产品也是一个技术，还是一个构造的过程。 最后，我通过一句话结束我的发言，希望在座的同行携手共进，成就明天。谢谢！

主持人：下面有请评委老师对丁思非进行提问。

周龙骧：从你的材料上看你现在还是在职硕士，就是说先参加工作？

丁思非：因为本科生的时候本来可以保研，但我放弃了，直接上了做计算机的所，做技术人员，大概做了几年以后又回到学校中去学习理论知识，现在学软件工程。

周龙骧：导师是谁？

丁思非：现在是赵亚伟和杨大川。

周龙骧：是处于怎样的一种动机呢？

丁思非：当时老师说要培养懂技术、精管理会做人的人，尤其上研究院的时候发现很多中科院的老师他们都有很强的基础，他们再去学习理论会非常快，对我将来的工作也具有指导作用。

周立柱：在你的第一个项目中，建立了一个很好的信息系统的数据模型，你能不能简短的介绍一下这个数据模型是个什么特点？

丁思非：我觉得这是我最近一年多一直在做的事情，我们是在咨询公司中做预算的，这个模型是数据模型为核心，从领导制订决策部署下面预算执行和预算分析报表中的一个环，其中有两个叫做模型的，一个是如何建立OLP（音译）数据库，另外是间隙企业绩效管理流程的模型。

乐嘉锦 ：你多次讲到OLP数据库，这是怎么定义的，这个数据库怎么叫联机数据库，是为OITP做的还是怎样？是口误还是确实存在这种概念？

丁思非：在我们的系统中是用到了一个OLP Server，我们在这个上面用到了一些API对联机分析处理引擎做了一个应用，我们的数据是一条条对OLP Server中写的，但存储的结构都是纬度，只有三个QO（音译）一个KO（音译），最后作出的模型也是这样的。对于运行其实非常简单，就是版本、时间、年月还有科目、业务实体，大概有十几个纬度构成了一个OLP（音译），最后定位在OLP Server上，所以是这样说的。

乐嘉锦：上一场讨论还蛮清楚的，或者是ODS层的库，或者是数据级式，或者是数据仓库，然后在这三个层上做OLP。

丁思非：为什么我一直在提创新呢？我们是利用了OLP Server去做了业务数据库存储的方式做的。

乐嘉锦：学术名词也在创新？这样我们就没有办法沟通了，我觉得有些东西可以创新，有些东西还是创新不了的。

丁思非：对对，没错。

主持人：下面有请第三位选手袁春光进行陈述。

袁春光：我一直从事小型机平台的DB2管理，所以我从我所从事的内容和工作上谈一下重点。 首先在数据库设计方面我把它分为以下几个方面。第一是逻辑设备，就是把所谓的业务实体到数据库里，比如规范化要遵守，保持一致性，保持数据关系的正确性。 第二个是物理数据，主要考虑在数据库里面存储的问题。在性腾方面考虑存储的效率，如何分布，以及几个IO层次如果形成。 第三个方面就是应用设计，比如经常会用到数据库中的概念很多都是为应用服务的，索引、视图，这些对性能影响都很重要，但我想这些设计、使用是根据应用需求在不断变化的，可能同样的数据要实现不同的需求目标索引可能建的就是不一样。 数据库管理系统整个的配置和操作系统方面整个的配置，这个我把它包含为三个方面概念。CPU、内存、IO，这三者都有一定纬度的关系，横向的来说这三个方面又有自己不同的特点，首先性能跟应用的类似关系密切，以及数据到底是OITP的，这样也有一定的规范。再有就是影响关联性，比如CPU，并行性是提高CPU的办法，主要是关于锁的办法，这又牵涉到内存的使用。第三是决定性的问题，比如规范化要求，既然是关系型数据库，关系型数据库通常来说一定要符合关系型数据库的要求。但性能方面却违反了各规范的要求，所以就要反规范化。 再就是方法论上的问题，性能往往是循环的过程，通常要建立分析流程，根据分析流程解决流程不断循环。 还有一个哲学概念上的问性能问题是很复杂，包括操作系统、数据库、应用程序、整个构架的网络环境、以及业务需求及特点，非常复杂，所以考虑问题要多纬度的考虑，不光是单一的纬度。 性能的调整具体的方法很简单，通过步骤间调整觉得是一个很好的办法。 我大概把性能方面同我的工作过程中把它总结为这几个方面。

周龙骧：刚才你介绍里头说到首先是进行逻辑设计，然后下一层是应用设计？

袁春光：对。

周龙骧：一般我们考虑是从根据应用需求进行概念设计，然后下一层是逻辑设计，再是物理设计。你怎么把逻辑设计跳到应用设计的前面去了呢？

袁春光：这是我表述的一个方面，主要是我关注管理性能问题，通常设计数据库系统一定要根据需求来设计，之所以倒过来讲，先引入业务方面的一些概念，有些关系已经确定了，把这些基本的关系确定以后，然后在关系之上如何满足应用方面的性能要求，如果是业务需求肯定是以业务需求为要求确定之间的关系，确定了关系之后如何满足性能需求呢？这就要根据应用需求的特点，比如索引要求等等进一步对性能有一定的提高。

周立柱：非常高兴你在谈论性能的问题时候有反谈的问题，如果你看一些书的话书里面已有这个事，另外你谈了索引问题，除了这些你还有什么经验，再给我们介绍一条。

袁春光：比如说最后一条简单化的一条，遵循一个简单的原则就是根据MQ再进行调整，看起来很复杂，但真正做起来确实很简单，有些人很挠头，真正贯彻了基本原则以后可能解决起来很简单，谢谢！

乐嘉锦：在你材料中讲了比较和数据库之间的操作关系，我们常说数据库新开起来可能有很多缺点传输就开始用了，等慢了以后要调整了，这时候调整往往是调整数据库内部的传输，我的意思是说数据量大的时候会影响数据库的传输，什么时候影响操作系统上的传输？

袁春光：数据库运行的平台肯定是在操作系统，比如操作系统的缓存使用，缓存是一个重要的方面，数据量大了以后这些会带来很严重的问题，虽然现在有自动配置的概念，但也不应该能完全解决这个问题，比如缓存数据库是一个很重要的方式，内存从哪里来呢？还是由操作系统来分配，整个就影响到数据库的使用，比如里面对内存的使用方式有些工作数据，有些文件数据，这些数据在操作上有不同的限制，这些限制直接影响到数据的库操作。IO也是一样，操作系统采取预取的策略，这些也存在IO的性能、平衡的问这两个层次支架的协调、交互很多时候是被DBA所忽略的。实际上很多问题源泉在于操作系统，虽然操作系统好象并不是非常的明显，但却是源泉在操作系统。

乐嘉锦：这这个回答肯定是不会错的，但操作系统在设置的时候基本上定了，如果数据量大了会有影响的话应该在开始时候没有设计好，我们调整大部分还是调整数据库内部的调整，但有的也不排除另外的情况，是操作系统有些地方的缺点，如果经常动操作系统肯定是一开始的时候没有设好。你说的完全正确，如果开始没有设计好操作系统的传输，不是因为数据量涨了而产生的。

袁春光：数据库使用的类型也会对操作系统有影响。

常红平：大家好！今天想跟大家谈谈我在从开发流程角度大型数据库方面的心得，大型数据库开发面临的一些挑战包括模块比较多，人员也比较多，甚至不在一个地方进行开发，第一点一定要按数据库功能创立多个数据库环境，如果是很复杂的话创建越多，最基本至少创建四个环境：开发环境、生产环境，管理环境，生产只是支持环境。开发人员在开发数据库上应该利用最大权限，在测试和生产数据库上应该有很多的权限。在生产数据库上开发人员的权限，只有发生问题需要人员参与的时候才由经理批准之后才可以，一个是代码管理一个是保障了开发数据库的稳定性。 要有一套完善的代码模板和代码规范，代码模板可以帮助开发人员，所有开发人员都是同样的风格。要有一套完善的版本管理的规范，包括在提交代码之前要确保代码是可以运行的，提交之前要由资深开发人员审查代码。还有就是要有比较完善的文档管理，要加强沟通，因为人一多够非常重要，模块比较多的话，我的经验认为，要把模块分开，最后要加强回归测试。

周龙骧 ：你刚才讲的拉几个经验都是常规的，这是你在工作当中总结出来的经验还是从书上学来的？

常红平：这是工作中总结出来的，因为现在开发产品已经有十年的时间了。

周龙骧：在你们的工作中特别是文档管理有什么体会吗？因为在科研学校文档就比较乱，在你们公司的开发中文档管理要强调什么？

常红平：首先文档要放在一个公共的地方，我们用的工具是W NOS（音译）来存取文档，文档的版本也需要管理，如果需要变更的话需要文档版本号还要指出文档的BUG在什么地方。

周龙骧：人员的变动是不可避免的，人员变动以后如何保持运行正常？

常红平：您的问题非常好，我们业务分布在新加坡也有美国，我们加起来有100人分布在不同的地理位置，人员变动确实是不可避免的，但是我们要求所有的开发有完善的文档，我们统一代码规，某个写一个代码其他人是可以维护的，所以我们不怕人走。

周立柱：做DSW的时候我看你的项目的数据量极为庞大，有没有数据的概念？

常红平：并不是很庞大，有3、4个表大概在700、800万条数据，因为汇表非常多，另外数据库的环境也比较多，除了开发测试以外可能还要用到 SP（音译）和其他的数据库互相交互。

周立柱：我看到你是高级软件工程师，对再生对数据库方面知识来说我猜想你不是唯一的，在你们的队伍中应该还有别的在做。

常红平：是这样的，因为项目要大的话分工也会比较明细，我是负责开发的，重要职责是带领我的团队开发，保证工作质量保证工作进度。

周立柱：我看到你在跟德国一家公司采用用金计算，我看到有一部分非常复杂，如果说再大还能做的到这么复杂吗？

常红平：确实是这个问题，当时访问的时候全部都是四个量，是用到4个G，如果数据量再大的话就会选其他版本。

乐嘉锦：你们使用动态SQL怎么提高性能。

常红平：实际上不是动态SQL，如果完全用动态SQL的话性能可能是达不到的，我们当时用SX连接动态QL的方式整个时间月1个小时，如果改为SQL G的话时间为3分钟。

乐嘉锦：但你上面写的不是这样的。

常红平：对不起，可能是我的笔误吧。

乐嘉锦：你是说动态SQL的性能是很难提高的？

常红平：对，是这样的。

主持人：下面连线一下钱彦云，请你做自我陈述。

钱彦云：尊敬的各位专家和同仁大家好！很高兴能在这里和大家交流，首先进行一下自我介绍，我本人主要工作经历是软件开发，有过几年PT开发经历，在IBM的AX上写过一年的标准C程序，目前主要在工作做.NET方面的WEB应用，个人曾经在铁路和电信两个行业都有开发经历。 下面谈谈现在做的关于一个电信客户流失的应用，首先要支持有效的客户挽留，有一个OSTP的应用，最后要在这个基础上做流失客户的统计分析，明年还会做客户流失的挖掘预测。 下面阐述如下几个观点，是关于这个项目的。第一，我们的开发采用了ER模型，首先在用ER模型做逻辑设计，之后在基础上自动生成物理模型，一直到数据库的部署，之后的阶段都是自动完成的。我觉得用ER模型做这个项目有几个好处。 第一，ER模型可以作为项目小组成员的交流工具。 第二，ER模型可以支持快速和优秀的设计。 第三，很重要的问题，我们这个项目还有RLTP的应用。 第四，ER模型支持快速修改。 由于工具的支持ER模型的变化可以很容易的投入到数据库，这就有点像前台的TOLM模型一样，用K（音译）模型就可以很容易用类型的变化反映到代码中去。我认为ER模型是可以用来做数据级式。 第二，取长补短，打破思维级式，一般我们的应用系统只使用一种数据库应用，各个厂商也各有特点，比如说ORACLE的数据库性能非常强劲，并且可以部署在UNIX环境上面，但SQL Server主要是节慢友好便于应用，而且现在的数据库产品线都比较丰富，除了关系型数据库以外一般都集成了前台的报表展现和多维数据库的支持， 我们的一个应用将从ODS获得的数据存储在ORACLE中，来支持客户挽留取得OLTP应用，然后把数据进行汇总，在用Server2005年进行数据模型，由于现在异构数据库访问非常容易，所以可以很好的集成在一起，同时也降低了开发难度。 第三，在加强需求和同客户的交流。对于我们来说行业应用多数都是数据密集型应用，在数据库设计上面要有好的基础，同样的应有好的设计可能只需要扫描一万条记录就可以完成，不好的设计可能需要扫描一百万条记录。分区索引都是依靠需求的，没有一个好的需要没有一个好的设计，SQL Server的设计都是无水之源头，都是建立在数据库设计的基础上的，但是目前工程师通常不进入费分析需求阶段，数据库设计是否成功要看项目管理人员的经历，这是一个不足。 第四，关于数据清洗，以前我们做一个票据审核，1000万条票据，入库后的票据使用了3个小时，如果先对票据进行预算，时间就可以控制在半个小时。 第五，有时需要反规划设计，比如大量数据在设计阶段我们使用紫外线。 第六，使用XML应用，控制系统的控制衔接，比如我们的项目有SQL Server和ORACLE两个后同数据库，我们模仿微软的PLSFOT（音译）模式，这样通过这种模式可以工厂化的生成数据库的连接串，同时数据业务层可以很好的交互。一般我们大部分数据库系统不使用XML方式，主要由于性能问题。我的发言完了。

周龙骧：你刚才提到在有的时候为了提高系统的灵活性要进行反规范化的做法，规范化的目的主要是防止信息丢失，现在你按是反其道而行之，你怎么知道信息丢掉了呢？

钱彦云：对于这种操作一般在生产系统我们都会使用泛式化的操作，这样保证数据库质量不会有异常数据进入我们的系统，但如果进行立体操作数据质量一般在EPR阶段控制数据的有效性的，进入数据仓库以后，尤其是需要多表连接的时候还是需要反应磁盘操作有些时候我们要把一些比较大的表在数据仓库中进行合并。

乐嘉锦：在你的材料里面写了ORACLE的设备有时不稳定，有时会失效，我对这个问题有些疑问，在什么时候会失效？如果真是这样的话ORACLE应该给我们赔钱了，我们用了它的触发器老是不稳定，会有这种情况吗？是程序不稳定还是ORACLE提供的东西不稳定？

钱彦云：触发器是有依赖的东西的，尤其在我们开发的上线阶段，表结构有可能会发生变化，在实际运用中触发器失效是常见的，像存储过程一样，以前我们对铁路系统有一个程序，有一段时间经常会发现数据计算不准的情况，后来我们通过观察发现存储过程合乎触发器会莫名其妙的失效，估计是他的依赖对象发生修改造成的，对于一个7×24小时的应用一定要实时监控触发器工作过程，对于触发器来说解决方案很多。去年我们做了一个电信的交帐开机系统，初始设计就使用触发器，但考虑到触发器一旦失效就会造成投诉，在关键系统应用上来为了不造成投诉我们把触发器的触发逻辑都写在PZ里面。对一些关键性的应用使用触发器和存储过程还是要小心。

周立柱：在你的申报材料上有一个工程师应用创新谈，第一页里面谈了你做的一个项目，一个叫数据仓库使用的NCR的解决方案，但又用了ORACLE关于数据引擎，多维数据库展现又跑到微软的Server2005年，有一句话说过三种数据库是异构的，带来有趣的问题，下面说如何解决ORACLE的办法，一句话采用文件接口方式，这是异构数据库采用最常用的方式，我觉得这个太普通了，我想知道这三个公司三个大产品合到一起去碰到一个应用里面有趣的问题，你应该讲到一个真的有趣的问题。

钱彦云：首先材料没有说清楚，我们公司的ODS系统实际上属于我们的一个上游系统，在我们的系统内部只有ORACLE和SQL Server两种数据库，作为上游公司我们和他们之间就是一个数据接口，NCR采用了文件接口，我觉得异构数据库之间比较有趣的问题，就是充分利用各个数据库的特点，像SQL Server的应用型很好，界面也非常好，我们可以用来作为前台的展现应用，像ORACLE它的数据引擎效率比较高，而且对海量数据的支持也比较好，对于初始过来之前的大量数据都是采用ORACLE来处理的。对于异构数据库来说，现在异构数据库之间的互联已经非常容易了，我觉得充分利用他们可以集成到一个应用里面去。

周立柱：接着再问一个问题，我觉得你干吗那么麻烦，如果我是企业的老总的话就会想到一个事，投资大了，买三套产品带来这么多麻烦，什么原因导致你这样做？

钱彦云：使用异构数据库会造成一定的麻烦，但是我们这个项目的特点是这样，对于ORACLE这个产品来说他的关系型引擎和OLTP的服务器是他的两个产品，我们需要分别购买，目前我们的设备投资只是他的常规关系型引擎，对于SQL Server2005来说它的价格比较便宜，我们主要是考虑经济运算。

主持人：谢谢钱彦云，不知道其他选手有没有对钱彦云的问题。下面进入第二个环节，把时间交给特邀嘉宾刘晶炜先生！

刘晶炜：听了各位的陈述，这一轮主要是实干，从在座五位都能够介入，其实是数据库里面很核心的问题来入手，数据库是解决问题的，资源是有限的，也就是CPU、内存、IO的资源，我现在只信问一个问题，从你们过去的经验中在不管是用哪种类型的数据库有那些策略更好利用内存资源，以及今天把视野开拓一点，今后业界的走势你们是怎样看的，比如说IO的调整和其他方面，这样会给各位一个比较宽泛的发挥空间。

李强：我觉得这个问题我的理解是一个PFS（音译），你怎么理解这个PFS（音译），对于刚如同行讲的哲学道理，我没有那么多的哲学理念，我的理解PFS就是时间和空间的权衡，在国外叫做COF（音译）妥协，我们在这曾经有过很多欢笑和泪水，这里可以谈一谈。比如说为什么用SFS（音译），就是确保你的数据库没有冗余，但是处于数据库各方面的考虑你需要做些妥协，讲起非规范化很多人头疼，这里我提供几招，第一招就是陈余列，冗余列，联合两个表操作，然后从其中某个表选择某一列查询信息的情况，创造一个冗余列，这个冗余列就是你查询的信息，这样从你多表的操作降成对单一表的操作。第二招，表分裂，大家肯定都填过很多表格，大家有没有考虑到这些表格并不是严格按照你们所填的存储的，对于像德意志银行、宝马、奔驰这样的大公司，这长表何其大，填的表是怎样的表不可思议，我们需要把需要查询的列放在一个表中，把不经常查询的放在另一张中，这样提高你的性能。 另外还有一招，我给它起的名字叫做统计表，如果对于有级几百万数据表进行统计，不如你在创建设计表的时候创建设计列，比如求和列，这样虽然每次插入的时是有点增长，但保证将来查询的时候极大的提高体的效率，当然这些是你用过的非规范化的方式。 我还提一点，除了DMZ之外还有其他的方式，比如大钟公司，他的交易表有几百万数据，他要求这张表不仅要实现日常查询功能，还要实现明年8月份跟去年8月份做比较，我要把每一年的8月份或者几月份做比较，这种比较处理，一般来说规范的做法是设计一个分区表空间，然后以时间作为分区表空间的关键字，然后进行排列记录，由于这里客户有特殊需求，如果用日常的正规化操作，年、月、日很好的排列，虽然可以很好的提高效率，但一旦做不同年不同月就很麻烦，这时候我怎么做呢？我用了一点办法，把它时间这一列分开，年拿走，把列作为分析时间。包括动态的SQL怎么调整，是不好调，但在DB2中是可以调的，可以把执行过的动态SQL放到内存里，下次你再执行的时候直接读内存就可以了，这也是调整动态SQL的方式。

丁思非：我们谈到的其实就是一个资源的问题，资源又是时间和空间，实际上对于调整性能不管是在OLP（音译）还是在SDLMS（音译）上，但并不是我们没有一定的方法和规则去解决这个问题，像现在我们做QB（音译），现在都是从业务方面考虑建几个维，建几个度量，但现在考虑更多的问题是怎么从这个数据库中构建这个QB（音译），从这样的角度并且把度量也当成一个纬度看待就会看到这个QB中有多少个BLOK（音译），纵线肯定会呈现这样的走势，CPU、寄存器然后CK（音译），实际上从这个线上慢慢的模糊，从横向上来说又是通过CLST（音译），又变得越来越异常，变得越来越模糊。

刘晶炜：你刚才提到多维方面的技术，我针对你这一点可以给你一个补充，你讲到SBS里面有两个层面，尤其是多维涉及多个层面，尤其是非常强的数据压缩。

丁思非：现在有很多的压缩方式，这样也可以很好的提高性能。

袁春光：我简单说一下这个性能，性能从我的经验来看主要是抓住应用的特点，应用多、查询多、更新多等等，根据这些应用的特点对各种资源的利用情况也不大一样，同样的资源，内存资源在数据库里面又有不同的利用方式，咱们应用了不同特点就决定了数据库里面哪个层次对内存用的多一点少一点。IO也类似，最主要的特点就是平行、并行的问题，在并行的情况下极大提高IO的访问量，最大的特点我觉得还是应用的特点，抓住了应用的特点就抓住了性能到底在哪个地方可以进行操作。

常红平：用我的经验来说，如果提到IO首先考虑到的是数据库参数。第二点就是一个建表的问题，再往下就是根据应用创建索引，同样的需求同样的索同样的数据库的情况下如果SQL语句列不一样的话性能也会发现变化，这里也涉及到不同的查询方式。 最后，在数据库方面性能是一定，对于整个应用上也是一个考虑方面，怎样用数据库。

钱彦云：我补充三点。 第一，应该从设计阶段开始就应该尽可能充分考虑系统资源的占用，比如说我们在多维数据库中，多维数据库之所以对OF查询就是因为有性能优势，提前会大大减少运算和资源的消耗，我们的前期设计应该做好，对于有展现需求的数据，尽可能的提前运算，这样会减少资源占用。 第二，IO的消耗方面，这样会影响CPU的效率，我们在设计优化的重心应该放在IO上面。再就是和操作系统的平衡，比如如果ORACLE的SPA和操作系统预留的内存设计不合理，SPA占用太多的内存反而会造成占用资源。 在UNIX系统上面共享内存和信号灯的设计对ORACLE本身的性能都有很大的影响。 第三，在前台设计，目前的应用一般都会在前台数据库连接缓冲时预留，同时尽可能使用页面级的缓存，数故从后台查询出来以后，在外部服务器上面会预留一定的时间，提高响应效率，也减少数据库的负荷。

刘晶炜：钱彦云你刚才提到的一个问题也提到了第二个点，在内存方面体讲到并不是越大越好，这里面涉及到各家数据库厂商如何动态考虑内存这个领域，动态管理内存过去很多技术是预先预留一块，现在很多趋势都往这个方向发展，你们有没有利用这方面的应用。

钱彦云：目前我们的应该是ORACLE10G，在这上面我看已经实现了自动划分，但和操作系统之间还是要提前预留的，虽然它的有关一个参数可以设置SXT（音译）最大可以达到的氛围，但还没有做到像您所说的在安装过程中会自动选择最优的内存空间。

常红平 ：在BD2V9中有一个非常好的性能是自动优化内存，现在DB2管理还没有完全动态管理的功能，尤其是7×24小时的管理动态管理是非常危险的。

袁春光：刚才这位专家已经说过了DB2内存调整的特点，因为现在V9正在推，我觉得他遵循的原则是比较标准比较普通的，具体到各自的应用特点，尤其是一些访问量比较高的，特点都很明显，这种自动分配自动调整就不大适用，我们还是要做恰当的分配才能适应需要。

丁思非：从ORACLE的角度一上来可能就把内存占完了，不断使用内存，SQL Server源下说是可以动态管理内存的，但实际的经验我见过把内存占完了就不会调整，需要重启机器。现在我觉得这个技术比较新，虽然各家厂商说自己能提出解决方案，但是这些算法不一定非常好，我们不一定他说什么我们就听什么。

李强：在IBM大型机上情况有点不一样，因为在IBM大型机制上面数据库是直接和内存打交道的，由于要管理好内存，在主机定位上要考虑一个问题，到底哪些东西要拿到内存中去，这些东西在内存中占的百分比又是多少，我们有这样一个的概念，就是一次拿一个页面。还有一个概念，就是顺序取，一次拿一大堆页面进来，如果是一次拿一个进来所占的比例多还是一次拿一大堆所占的比例多呢。如果这个业务只是一般的查询，这里内存中摆的越来越多的情况比较好，所以有一个参数叫VPSAT，把这个参数做的高一点。如果是做培训的，一次拿一大堆页面，这个时候就不要把单一界面的数据设的那么高了，所以说这是性能调整设计上的问题，这方面是需要经验的，另外IO，突出表现就是分区表方面的处理，这么大的表，表现在哪个盘上，这些都是考虑的，尤其是在做物理设计的时候。

刘晶炜：谢谢你们的观点和讨论，从我的经验来看就像今天开车一样，手动档有手动档得好处，自动档有自动档的好处，在应用方面你们也讲到了，有些问题是很通用的问题，谢谢各位分享你们的经验！

主持人：谢谢刘晶炜，本场评选进入到最后一个环节，有请专家对本场评选进行点评。

周立柱：我们可以看出这些选手有非常丰富的实践经验，这场讨论的比上一场讨论的更细，讨论到内存和规范化和反规范化建立的问题，深度还是很深的。第二选手在讨论问题中和回答过程中都表现出了很强的自信心，由于他们有很好的基础和经验所以他们都那么自信，在问题的回答中有表示了对问题的理解。 我想还是有几点需要大家一块共同提高的。第一，还是要学习，因为数据库的领域实际上本身发展也很快，大家都在第一线从事工作，现有的技术马上就要变成第一线所需要的。比如说安全问题，现在数据库里存的不再是结构化很规整基础类型的数据，而是非结构化的，大多数是多媒体数字化的东西，这些都会对我们的数据库提出新的要求。 再一个非常同意也非常高兴大家能看到这个观点，数据库是面向应用的技术，如果强调什么东西，我说是应用，应用还是应用。比如理论上讲如何建索引，如何调整性能，考虑到参数如何调整，但如果进行折中一定要考虑应用，比如第三方设计好了，如果带来不一致问题，那么可以放松这个要求，这实际上都是跟应用相关的。 第三，我觉得我们一边讨论问题，你们也展示自己和我们交流，时间都很宝贵，有时就限制这么长时间，要长话短说，我觉得我们在讨论问题的时候也是一样，大家坐在一起时间也不是很多，但一定要用最短的话表达最多的信息量。

周龙骧：我有一个感受，咱们在创新的时候一定要已有的基础上站在别人的肩膀上往上创新，而且一些通行的理论技术都是通过全世界的同行千锤百炼，基本上在这个上面创新的余地一般是没有的，所以说最好把精力集中在真正新的方面创新。以前我国有一些经验，算法语言，结果每一家开发出来的都一样，都想创新，但基本的东西都一样，低水平的东西反而不能一致，不能规范化、标准化，所以我们要创新就需要在真的新的领域上创新。

主持人：谢谢各位老师，关于数据库文学的话题还可以继续探讨下去。那么到现在为止“2006年中国首届杰出数据库工程师评选”终选到现在就全部结束了，谢谢各位评审老师！谢谢各位参赛选手！

 

原文网址：http://event.ccidnet.com/broad/gongchengshi/index.php