【聆听IT专家讲座，了解如何降低数据管理成本，更有机会获得限量蓝牙耳机！】
【了解更多数据管理产品信息。】
序言:最近看了不少国内、外同行对DB2 9的评论，内容上虽然百家争鸣，但基本上体例都是一样的，依次分别是PureXml、自动内存管理、表分区、数据压缩、基于标签的访问控制(LBAC)……，此外作为开发人员笔者还想就Viper对Visual Studio .NET 2005和Eclipse的Add-ins 的使用情况作些简单的介绍。
此次版本的DB2 V9 正式发布前差点被命名为DB3，虽然最后还是沿用DB2 的名字发布，但是从可以被考虑命名为DB3这件事本身就已经说明了这个版本较之DB2 Ver3 至DB2 Ver8之间非常大的差别，最直接的原因也是因为它进入了双核的时代。
相信读者中很多人也都经历了从桌面的C/S 环境到Web的B/S环境的转变，您在技术中的很多问题也源自或者归咎于数据库的支持能力，那么下面笔者与大家一起评测DB2 9 的表现。
来自业务的呼声——PureXMLXML
数据的保存方式
开启话题之前，简单看看现有关系数据库系统中对XML的3种主要保存方式:
◆ Shredded方式:也就是把XML数据抛弃其层次关系，平铺为关系数据表，这对于一般的单层或者简单的XML数据交换而言可以接受的，但如果需要通过XSLT转换或者交换不同XSD 的数据就只能靠关系数据库的关联操作完成。
◆ 非结构化的BLOB方式:这种方式被“三大”(Oracle、IBM 和SQLServer)的上一代产品使用，虽然提供了XML Extend 但是其实都需要把XML数据从BLOB 中完整串行化后，才可以在内存的树型结构上操作。
◆ 结构化方式: 这个方式是“三大”这一代产品的方式，保存在专门的XML 字段的数据是具有层次结构的，因此可以不用把整个树串行化到内存就可以用XQuery 借助XPath定位到某些层次和属性的信息，是真正的XML 数据方式。
结构化存储的技术意义
那么DB2 9这种纯XML 数据访问方式在技术实现上有什么实际的意义呢，笔者总结如下:
◆ 只有真的结构化存储，才可以提供层次型索引，作为可用性的基本要求——保证效率才可以真正把Native XML数据库大量用于开发。
◆ 现有XML更多的使用位置是在数据交换中，XML数据的转换主要有如下几种：基于XPath规则的部分提取、基于XQuery 的部分更新/ 增加/删减、基于XSD->XSLT->XSD的schema转化、多个相同或者不相同Schema数据的合并。如果不提供这种结构化存储，那么每个操作都至少要把整个XML 数据完整提取到内存中，再进行计算，尤其是涉及多个XML数据的关联与合并操作，那么资源的消耗就很可观了，即使您可以通过分解等价式将一次操作等价的通过多次操作累积完成，那么情况相信也是很糟糕的。但是在层级结构下，每次提取的都是部分子集或者是基于某个层次的个别统计结果，即使进行关联操作内存的消耗较之非结构化也应该是1-3个数量级的。
◆ 只有通过这种结构化存储才可以保证SQL与XQuery 可以混合使用，否则以往的SQL解析器根本不能从没有结构的二进制数据中知道查询的那些层次和属性是否存在，更无法确认是否应该使用那些索引，所以执行计划的建立只能是梦想而已。
结构化存储的业务意义
这些技术层的要求又来源于我们哪些实际业务需要呢？
◆ 就像笔者上文一直强调的，第一个见效益的就是服务器的投资上可以大大降低，因为完成同样的吞吐现在都是数据子集对数据子集操作，而且通过XML数据的索引可以大大提高查询的效率。
◆ 原始数据的价值恐怕经过几个交换和汇总后会有很大的提升，那么在互联网环境下XML 数据作为交换载体就非常方便了，但是其中有几个主要的挑战:
1. 由于业务的快速变化，数据结构也常常需要变化:有了结构化的X M L 存储一方面可以快速的采用XQuery 修改数据Schema，此外更便于套用XSD来验证数据的有效性，这样数据交换的原数据检查和入库前的检查都有了保证。
2. 同一数据往往需要与不同的业务伙伴分享，但是不同业务伙伴需要的schema是不同的:这个就更依赖于结构化存储，通过配置不同的XSLT就可以轻松的“因人而异”准备数据。
3. 便于业务流程的合并和重组:以往的关系化设计更类似于结构化程序设计，要求每一步都“ready thengo”，但是业务流程又常常是在变化的，不断会常常出现新的业务，而且出于效率和人力成本的考虑很多业务也会常常合并，那么体现在XML数据上通过XQuery 快速的拆分、组合XML 树型结构是非常方便的。
4. 各个厂家的业务处理限于历史的原因，技术平台不一，数据交换需要采用可以适应不同平台的“中庸”数据存储方式：这个是XML数据的天然优势。
◆ 可以更为丰富且规格化的描述业务信息。
以往的设计中往往为了开发的方便，也出于效率考虑，可能需要增加一些冗余的字段，例如图1。
采用XML字段后:假设联系人信息的Schema如下（重数和层次关系都已经标出）例如图2。
那么完全可以以更规范化的表示用户信息如下，例如图3。
◆ 此外，DB2 9这种方式也是很好保存各类企业关键历史资源的有效途径，企业中更多的信息价值是保存在Word、Excel、RTF、Powerpoint、Project 之中，以往我们总是把他们作为附件，很多企业知识其实是被浪费了。有了Viper 的PureXML 数据库后，通过Office 到XML文件的导入机制，我们可以把他们保存到数据库中，利用公文格式相对固定的特点，通过XQuery很容易实现基于原有OA系统的统一的公文检索。
