博文专访——与作者面对面
胡百敬 老师谈SQL Server 2005
针对
采 访 人：博文视点首席策划编辑刘铁锋（Joylite）
受 访 人：胡百敬
采访方式：电子邮件
Joylite：
百敬：
其实，早在2002年台湾微软举办TechEd研讨会时，他们就邀请我讲SQL Server 2005的设计理念，那时根本不晓得何时会出，以及产品正式名称为何，只知道Code Name是Yukon，以及它的目的为何。但从那时开始，其后，我在每年的TechEd都有一场关于SQL Server 2005的演讲，让自己一直关注着这个产品的动向。
或许因为自己有多重身份，既是认证教育培训中心的讲师、微软及多家厂商的顾问，又是作者、演讲者，因此微软会提供一些先期的信息给我，让我得以研究，以准备后续对各大企业项目的规划、导入、研发、调校和维护等。
SQL Server 2005总共出了16个Beta版本，我大概测试了10个，外加两个中文Beta版本，昏天暗地中，不断地学习、比较、重测。信息技术是我的兴趣爱好，虽然忙碌和常常陷于对某项技术不知所云的焦躁和苦恼，但是强化了每有会意便欣然忘食的乐趣J
随着产品上市时间的临近，我除了赴美以及香港等地受训外，也开始积极准备国内的教育培训、编写演讲稿、专栏和教材。同时参与先期导入的工作，试行新技术以验证其优缺点。写书一直是我凝聚与沉淀技术的方式之一，例如以往在编写如《Microsoft SQL Server性能调校》、《SQL Server商业智慧圣经》（繁体版）等书的过程中，会强迫自己研究、试行、比较，这些与企业顾问的实战经验相辅相成。自2004 年底开始，一年多来，以聚沙成塔的方式完成《SQL Server 2005数据库开发详解》这本书，期待对新的观念与技术能有较深入的介绍。
Joylite：
谈到您以前的《Microsoft SQL Server性能调校》一书，不禁让我想起了当年拿到样书的兴奋之情。我以前从来没有看到哪本书能够从如何提高数据库设计和访问性能的角度来探讨数据库的设计以及数据库的查询效率。能请您再简单谈谈这本书么？
百敬：
早在16年前当学生时，我就以跑单帮的方式，用Quick Basic、C、DBASE III、Clipper等程序语言和数据库软件帮机构、学校、商店编写简单的数据处理程序。后来有幸进入到最大的中文报系——联合报系服务，开始处理企业级的数据问题，也展开了迄今约10年的MS SQL Server研究著述生涯。其间，一再碰到数据库的性能问题。可能原因很多，如设计不佳、累积大量数据、用户习惯改变等等。
数据库性能不好的原因千头万绪，如同汽车开到一半抛锚了，往往引擎盖一打开，对着复杂的机件束手无策。企业内信息系统的复杂度更甚于汽车，因为多个产品搭配组合，工程师们结合商业需求的智能结晶，还有成百上千的用户参与其中。细心、耐心、对技术的广度与深度的掌握，是性能调校工作的基本需求。
SQL Server在 SQL Server 2000版本进入到产品的成熟期，不论是功能，还是口碑，都很好。中大型企业的核心系统也渐渐采用了SQL Server，但因为应用经验不足，往往用一段时间之后，就会出现性能问题。
在代表台湾微软公司参与多个性能调校的顾问项目后，当时的SQL Server产品经理希望我收集资料配合实战经验，在教育训练中心开一门关于性能调校的课程，帮助SQL Server的DBA们处理这类问题。授课一段时间后，在大家的强烈要求下，整理编写了《Microsoft SQL Server 性能调校》一书供DBA参考，帮助他们了解性能不好的可能原因为何。
Joylite：
从《Microsoft SQL Server性能调校》一书中，我们看到了您多年经验的积累和总结。您是否可以谈谈目前这本新书《SQL Server 2005数据库开发详解》的写作思路和读者定位？ 是否对新技术还会有相当深入的分析和比较呢？
百敬：
《SQL Server 2005数据库开发详解》的定位是广泛地介绍SQL Server 2005的各项新功能，毕竟这是微软投入重金、1000多人耗时五年集结而成的旗舰产品，不是一时半刻可以融会贯通的，也不是任何系统都会用到所有功能。我相信渐渐地会像Office一样，大家都会选择自己想要用的局部功能。因此我想先写一本书，让大家知道SQL Server 2005关于开发的新功能，或是至少有个印象。毕竟，程序设计与数据库管理是我比较擅长的领域。
SQL Server在基本架构上一直是延续的，如它的数据库核心、T-SQL语言、安全基本架构，以及几个主要的服务，如：SQL Server Services、Agent Services、Analysis Services、Reporting Services等，其功能角色不变，协作关系也非常清楚。
而.NET技术和XML规格已行之多年，我从1999年开始研究XML、2001年开始玩.NET，SQL Server终于在这个版本提供了融合与统一，这会对那些正在犹豫是否要进入.NET/SQL的IT从业人员有临门一脚的功效。
对于技术整合我一直非常有兴趣，学习与经验能发挥作用是淋漓畅快的，有豁然开朗左右逢源之乐，在技术间穿针引线自由挥洒。当实现出XML与关系数据可以一起显示在同一句查询语法中，或让网络上的数据可以通过.NET与本机数据库集成显示时，那种一致性的满足难以言喻。
通过《SQL Server 2005数据库开发详解》这本书，我想将“可能性”介绍给广大的系统开发设计者和数据库管理员。技术的融合与成熟会让大家有更大的挥洒空间，发挥对信息系统的创意。这本书属于全面入门指引，对于各项技术的介绍不是特别深刻，这需要各领域在实际应用之后，累积数年的Best Practice，然后才能结晶出Design Pattern。
Joylite：
在SQL Server 2005的体系中，我们可以看到了很大的转变。甚至可以说是革命性的转变。一个是内嵌了对.NET的支持，同时对XML的功能进行了增强。您如何来看待这两点对SQL Sever 2005的转变？那么对于程序员来说，应该怎样才能适应这种转变？
百敬：
一直以来，IT人员都有多项技术选择，针对不同的应用方面，有着许多专属语言与开发技术，然后在特殊的平台与引擎上执行。工程师往往是一头栽进某个领域后，就偏好用该领域的技术解决所有问题，这设计到分析设计的逻辑偏好，开发、维护和管理的集成环境与团队默契。讲句题外话，所以刚进入职场选工作很重要，若将青春耗在没有前景的技术上，那是很可悲的。L
种种因素，导致编写Basic/Java/C等程序语言的人，在数据层不喜欢用SQL语法写存储过程、自定义函数、视图等，习惯于用程序语言直接访问基础数据表，解决所有数据处理的问题，这会丧失弹性、效率与安全。反之亦然，习惯于数据处理的人，听到非SQL语法的数据处理解决方案往往就会皱起眉头，惧怕其技术的复杂度，而这紧缩了数据处理应用的广度与深度。
现在，SQL Server 2005让.NET的技术可以直接扩展到数据引擎核心，让技术人员有更多的选择，以单一技术涵盖更广泛的层面。但因为界限模糊掉了，在设计时就需要更谨慎规划，以取各项技术的优点来完成系统。因此我们先来讨论一下各项技术在不同应用时的优劣。
将.NET开发的组件集成到SQL Server中有以下的好处：
l 强大的程序逻辑：.NET Framework中的类大都能够引用，藉以扩展SQL Server的功能。
l 安全：.NET在程序编写与执行环境安全上下了很大的功夫，相对于用C/C++开发出来的扩展存储过程来说，SQL Server执行根植于CLR的组件也就更安全与稳定。
l 统一的开发与调试环境：由于Visual Studio 2005的便利性，将可提升开发SQL Server 2005对象的品质与效率，并让数据层与应用层的开发经验一致。
l 性能和扩充性：.NET是编译，T-SQL则是以直译的方式执行。所以较为复杂的商业逻辑用.NET的语言编写较佳。
l 多语言选择：不管是Visual Basic，还是C#······只要熟悉该种语法，即可开发SQL Server的对象，而不像以往一定要凭借C/C++才行。
虽然用.NET语言开发程序有很多好处，但它仍无法取代SQL语言，以及纯以T-SQL编写的SQL Server对象。T-SQL是SQL Server的原生语言，它无所不在，有其不可取代性。我们一般用T-SQL维护数据时，可以广泛地分成两类行为，一类是数据查询与维护，也就是直接引用SELECT / INSERT / UPDATE / DELETE等T-SQL语法，另一类是程序逻辑，也就是使用WHILE、SET、建立游标等语法。而大体来说，.NET是提供程序逻辑的另一种选择，数据查询与维护依然是以T-SQL为主。
搭配索引的数据集合导向运作（Set Orient），也就是批次大量数据处理，依然以T-SQL为佳，在访问数据时，应当尽量发挥T-SQL的功能。尤其是在SQL Server 2005大幅增加T-SQL的能力后，你应当先研究如何通过T-SQL完成需求，然后再以.NET CLR补其不足。若将所有的商业逻辑都搬进到SQL Server势必大幅增加服务器的负担，因此仍要慎选程序逻辑的执行位置。
由于.NET语言编写程序的特性，程序员很有可能习惯性地组织T-SQL语法，然后传给SQL Server。虽然.NET编写的SQL对象存在于SQL Server 2005之内，但依然是一句句独立的T-SQL语法交由查询引擎执行，查询引擎仍要解析、确认、建立执行计划等等。相比之下，静态的T-SQL所编写的对象只有在第一次执行时需要建立执行计划，因而比较有效率。另外，若基础的数据维护，也就是单纯添加、修改和删除等操作，通过.NET编写的对象再传进SQL Server查询引擎，等同多了一层调用，速度一定比直接调用执行T-SQL慢。
最后，大多数的DBA听到SQL Server支持.NET后，第一个反应是如何关闭该功能，毕竟DBA要的是稳定与安全。以往若程序员开发的用户端应用程序有臭虫或安全漏洞，可能只危害到某个用户，就算系统崩溃或安全信息外泄也是该用户倒霉。但对于公司核心的数据库服务器，可能有多个重量级应用系统架构都依存于该服务器，若将有问题的组件植入，会危害到全公司，DBA不可不慎。
我们再来讨论一下你的第二个问题：XML。
电脑的使用不外乎程序逻辑与数据，微软似乎正努力将数据的使用与XML画上等号J，毕竟XML先天具备易解读、标准开放、可扩展、跨平台的优点。而各厂家企业级的系统与应用程序也莫不与XML以及Web Service整合。如何管理日益庞大的XML数据变成需要慎重考虑的课题。
SQL Server 2000版本就已经增加了对XML的支持，然后也一直以SQLXML单独安装文件，通过Web下载的方式提供新增的功能。而在SQL Server 2005大幅增强了XML数据访问的功能。
例如，新增原生的XML数据类型（Native XML Data Type），可以为该类型的变量或数据字段定义XML Schema来验证数据的输入与更新的正确性。通过业界标准XQuery（W
搭配XML数据类型与XQuery的SQL Server 2005是一个全新的里程，为了有效处理XQuery与T-SQL并行的执行计划，SQL Server的查询最优化引擎必须要重新改写，以最优化这两种截然不同的数据类型一起访问。在目前，我们踏入这种全新的应用模式，在验证过的最佳使用模式的经验尚未被大家建立起来之时，正是各种想象力奔放的时候。或许现在SQL Server 2005的XML引擎尚未提供最佳的性能，但随着软硬件技术的推移，相信性能将不会是问题，而数据使用模式将出现全新的风貌。
Joylite：
我一直有一个疑问。在使用.NET程序来编写存储过程、自定义函数、以及触发器之后，原有的设计模式是否会改变？也就是说，从性能或者易用性等角度来看，程序员在设计数据库逻辑的时候，是否需要有非常大的改变？如传统的展示层 →业务逻辑层→数据库（存储过程）→数据库，是否可能会转为：展示层→业务逻辑→..Net数据访问逻辑→数据库？是否需要新的经验才能适应这种开发方式？
百敬：
程序设计的模式从未固定过，随着信息技术日新月异，商业模式推陈出新，两者互相引动，让信息工作者疲于奔命。在企业主管来看，IT不变就是怠惰。而如何在对的时机，设计出弹性的架构，引进适合的技术，尽量发挥既有投资，又可以配合潮流演变，这是困难处。随着选择性变多，我们需要宏观的架构工程师，以指引团队的方向。但我要强调的是设计是巧思，是艺术，不要为技术而技术，KISS（Keep It Simple and Stupid）是不变的原则。没有绝对的好技术，只有合用的技术。别忘了，探讨合用时，还需要包括人员对该技术的掌握能力、技术前景、相关系统的整合配套能力、拥有成本等等。对内的仔细审视，因势利导，比追潮流重要得多。
设计系统时，层次分明（Layer）很重要，或许实体上并没有多台机器，但逻辑上依然要区分清楚。你的题目点明了一般的基本层次，但哪一层要用何种技术？由于层与层间界面的标准化，让选择充满弹性。毕竟你还要兼顾上述团队成员的技术成熟度，整体拥有成本（TCO）等诸多方面。或许目前迫于某些形式，而用某项技术完成某一层，但若设计得好，以后都可以轻易地替换掉。至于“ .Net数据访问逻辑”，如同我在前一个问题强调的，依据用户商业逻辑的需求而决定。但就系统架构师和程序员而言，他要具备这个能力，设计系统时才能够做正确的决定。但因为商业逻辑的需求差异，这个层级并没有必然如何的使用方式。
Joylite：
在SQL Sever 2005中，对传统的Reporting Services以及DTS做了很大的改进。分别独立出了Reporting Services和Integration Services。以您的经验来看，功能的增加对现在程序员是否提出了更高的要求呢？
百敬：
这要看该程序员所负责的工作，若是负责数据处理以及显示，影响会很大。尤其对于大型企业，数据的整合与显示是非常沉重的负荷。就我亲身的授课与顾问经验，不管是在美国还是台湾，DTS简单易用，都是数据整合的要角。
对于你这个问题，我也分两方面来谈，首先是Reporting Services，报表一直是各信息系统所必备的，企业内各层次的人员都有不同的报表需求，所有信息系统或多或少都有报表的产出。因为用途广泛，用户参差不齐，所以报表系统的成本必须低廉，可访问各种数据来源，其开发环境的功能丰富但操作直观，维护容易，还要让程序设计人员易于将报表整合在自己开发的应用程序中。
报表在新兴的商业智能领域更是兵家必争之地。微软报表服务在2004年1月推出后，由于简单易用，系统架构具备扩充性，符合各类型企业的需求，且版权费用算在SQL Server之上，因此立刻广泛地流行开来。
Reporting Services的设计诉求是报表平台，而非仅是程序设计员开发应用程序时，辅助提供一两张报表的工具。它支持报表的全生命周期管理，从设计、管理、使用、派送到扩展开发一应俱全。Reporting Services 2005再次加强了与用户交互的界面与报表设计环境，扩增数据源的弹性。另外新增一般知识工作者可用的报表设计环境Report Builder，并提供程序开发者方便使用的Report Viewer控制项，让报表服务的用户可以用更简单的方式完成更丰富的功能。期待它可减轻我们有做不完的报表的无奈，能满足用户永远需要新增修改报表的需求。
再就Integration Services而言，当你有各种数据格式或内容需要转换、整合，将数据搬有运无，也就是有不同的数据源与目标时，你可以通过文本文件、ODBC、JDBC、OLE DB、.NET Data Provider等，搭配程序或工具来互相转换数据。
在以往当我们要把其他系统的数据，如大型主机上的文件、dBase/Clipper/FoxPro的.dbf、Excel的.csv、Access/Jet的.mdb乃至于SQL Server/Informix/DB2/Oracle等数据库，或是.html/XML文件彼此互转时，都需要自己动手编写程序，而这些转换的操作往往还特别需要注意错误处理，将有错误的记录另外存放起来供事后查看等。因为不同系统的需求不同，且新旧系统或是其他非数据库系统在设计时，大都没有注意到关系数据库的正规化以及一些相关的需求，所以数据内容很可能不符合我们所定义的数据规格。为了提供数据整合更佳的效率，更丰富的功能，SQL Server 2005放弃了之前相当成功的DTS，改用.NET完全重新改写，务求提升性能和增添更丰富的功能。
SSIS从核心重新开发，成为脱胎换骨的新产品。其中最大的变革之一是将流程管理与数据转换分成两大引擎来处理。这提供了较佳的流程管理与数据处理的细节可见度，同时增加了用户自行编写程序扩展SSIS的方便性。新版本在执行程序的流程管理、错误处理、对象设置、调试、部署、执行记录、效率等方面都有长足的进步。
整合数据与显示报表是数据处理人员日常的业务，随着系统变多，数据量巨幅累积，需求琐碎、变化多且繁复，如同凿山开隧道，不可能再标榜用圆锹，榔头徒手蛮干。数据整合与显示也不再是程序设人员日夜hard coding可以应付得来的，强大的工具将不可或缺。
Joylite：
SMO是SQL Server 2005里面提出的一个新的功能。让程序员有了可以通过.Net控制SQL Server 2005的各种对象的能力，您觉得这种功能的提出意味着什么呢？ 这些功能将主要应用在何种场合呢？
百敬：
若想要自行编写类似SQL Server 2005的SQL Server Management Studio管理程序，以及通过WMI管理SQL Server旗下的各种服务，如SQL Server Configuration Manager。也就是你想要将管理功能整合在自行开发的程序中，就需要SQL Server提供的管理对象。
SQL Server 2005将管理对象由以往的DMO（Distributed Management Object）换成了SMO（SQL Server Management Object）。前一版的DMO是遵循COM规格开发而成的，而SMO则是架构在.NET Framework 2.0上，你可以通过其丰富的类完成各项管理工具所提供的诸多功能。SQL Server 2005为了向前兼容，依然支持 DMO，但功能不如 SMO 完整，因此，若你想要自行编写程序来管理SQL Server 2005，还是研究SMO比较好。
Joylite：
SQL Server 2005中，XML的加入以及XML存储格式的加入，您觉得意味着什么？这种功能的加入是否对表的设计、索引的设计等带来了更高的要求呢？这样的功能结合ADO.NET 2.0对现有开发模式的冲击是什么？
百敬：
SQL/XML/ADO.NET 2.0提供整合的XML处理，让系统设计与程序编写都有更佳的选择。但是否有冲击，这要看你怎么用XML了。我无法评估对你的冲击，但解释一下技术选择的关键点，让你自行抉择J。
虽然在数据使用上，XML已经普遍流行于较为新型的应用程序，以SQL Server自家的系列产品为例，如Reporting Service定义报表，SSIS定义包，Analysis Service定义结构，都是使用XML。而.NET 的.config文件、ADO.NET的DataSet与XmlDataDocument类的互通，Web Service/Remoting乃至于 persist对象的序列化，或是BizTalk交换表单，Ajax暂存数据等，XML的应用真是无所不在。但你看现今XML存在于数据库内的方式，仅以大型文本字段来当作储存区，与一个文件系统无异，这好吗？怪不得在SQL Server 2005的技术文章中，都大大赞扬SQL与XML的结合将再次带来数据处理的革命。
在数据储存上，XML与关系数据库一直无法顺利地整合，毕竟XML是以垂直、层次、递归的方式在描述数据，而关系式数据库却是利用数据表间水平、关系的方式来储存数据。因此以往要利用关系式数据库储存XML数据时，不是利用DOM对象，将元素与属性解析成各数据表的字段，就是利用文本字段将整份XML放入数据库中。这种做法有着非常多的缺点，约略如下：
l 无法简单地以XML Schema验证数据的正确性，需要前端程序的帮忙。
l 若以文本字段将XML整份数据放入，无法有效地建立索引，且无法以XML的查询方式（XPath或XQuery）找数据，只好以全文索引的方式来搜寻。
l 若将XML拆开成多个字段，通过XML View（Annotated XSD简写成AXSD）来使用数据会扼杀XML原来具备的扩展性。也就是说以往关系式数据库只能将XML当作一份文件，所有XML的特色都需要前端程序自行完成。
在SQL Server 2000中，对XML的支持主要在将XML的数据转成关系式数据的存放方式，以载入到各相关的数据表中。同时，在数据从关系式数据表中取出时，也容易转成XML的显示方式。意即所有储存与查询的特色，依然以关系式引擎为主，但SQL Server 2005则将这个状况完全地改头换面，储存与查询的方式，可以原汁原味地使用XML相关技术。但存放关系式数据与XML类型数据的差异在哪呢？若你的数据结构清楚明确且变动不大，关系式数据库是最方便且有效率的访问机制。但若数据结构需要弹性变动，甚至结构不明确，则适合通过XML存放数据。另外，你可能因为下述考虑而采用XML：
l 需要跨平台，跨组织交换数据。
l 数据本身的结构关系很重要，例如具有层次性，可能递归出现，或元素间有顺序关系。
l 查询、更新数据时，需要引用结构关系。
若你的数据没有上述的需求，可能用关系式结构来放数据依然是较成熟方便的技术。而一旦有了大量的XML数据，是否要存放在SQL Server内呢？还是简单地放在文件系统上即可？以下列出放在SQL Server 2005的好处供你参考：
l 管理上的一致性，例如整体数据的备份/还原、安全管理、复制（Replication）。
l XML数据访问需要搭配其他相关记录字段一起做事务管理。但要注意的是则整条记录可能都会因此锁定较长的时间。
l 需要验证数据的正确性，例如Well-Formed和通过XML Schema确认。
l 前端应用程序访问技术的一致性，统一用相同数据库访问对象，如ADO.NET，与SQL Server 2005访问数据。
l XML数据与其他的数据字段有关联，在访问时要互相参照。
l 通过XML索引提升查询XML局部数据的效率。
另外，若仅仅是要一个存放的地方，所有的运算逻辑本来就已经编写在程序对象中，但需要前述管理上的优点，则你可以考虑将手边的XML数据用nvarchar(max)或varbinary(max)的格式，单纯地将全部的文件存入记录并整份取出，不局部查询与更新XML内的数据。或许你可以从下面的五个方面考虑是否要将数据以新的XML数据类型存放在数据表字段中，或是依然将文件拆散成各字段存放，从数据库提取出来后才转成XML：
l 储存：XML字段的数据依然是大型二进制数据，若数据大（如产品的操作手册）则整体的XML解析一定耗性能。
l 查询：是否要查询到XML内的局部细节数据，如某个元素或属性的值。
l 索引：是否要针对XML的查询类型建立特殊的索引。
l 更新：是否要更新XML内的局部细节数据。
l 确认：是否需要通过Schema确认数据的正确性。
Joylite：
商业智能（BI）是现在比较热门的概念了。在SQL Server 2005中，也增强了对分析服务的支持，在您的新书《SQL Server 2005数据库开发详解》中是否有讲述呢？您对此有什么看法呢？
百敬：
与分析相关的服务是SQL Server 2005非常重要的一块，在与开发相关的新功能介绍中，它是不可或缺的。J
数据分析的需求随着企业规模变大，管理变得更加复杂。因信息技术成熟而大幅累积可分析的数据，商业竞争日趋激烈等等因素，将蓬勃发展。目前，它是SQL Server攻城掠地的主力之一。因为它的主要对手在这一块领域起步较慢。
SQL Server从三版以前，也就是7.0版引进了分析的功能，Analysis Services和Data Transformation Services初次加入产品线。至今在市场上已有七八年，渐渐取得该领域的领导地位。随着SQL Serve 2005大幅增强功能，顾问服务、协力厂商技术逐渐成熟，用户对产品的信任与了解，蓄积了多年的动力，至今正在引爆点上。
事务型系统，如ERP，主要是把事情做对。也就是客户的货给对了，员工的薪资、休假正确，物料不会积压也不短缺等等。但是，或许在你把所有的事情都做对了之后，才发现原来整个目标的方向是错的。我想强调的是：做对的事情远比把事情做对重要，分析型系统是让你做对的事情。信息系统若仅仅是操作，那负责系统的你我永远是公司的中下层，做的是支持、打杂、黑手的工作。惟有提供分析的能力才能进入决策阶层。也惟有提供分析的能力，大家才能通过信息系统做正确的决策。做对的事情，而不仅仅是把琐碎的事情做对，也才会进一步提升信息系统的价值。
在《SQL Server 2005数据库开发详解》这本书中，我有概观地介绍SQL Server 2005在分析面新增的功能，如Analysis Services和Reporting Services较前一版增强的部份，以及取代DTS的SSIS。由于分析本身是一个需要深入探讨的议题，我将会在进行中的两本书《SQL Server 2005报表服务设计实务》和《SQL Server 2005数据整合服务圣经》完成后，着手改版《SQL Server 商业智慧圣经》（繁体版），希望能结合已有的顾问经验，深入探讨分析系统的建构。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=745790
