明辉手游网中心:是一个免费提供流行视频软件教程、在线学习分享的学习平台!

XML数据库探讨

[摘要]存储 在资源库中存储信息很简单。如果希望存储的信息已经是 XML 格式,那么可以直接把它添加进资源库。这也许听起来不错。毕竟在不断创新的 Web 服务世界中,将要到来的多数信息将使用嵌入在 SOAP 消息中的 XML 片段格式。然而,把 XML 文档分解并保存到关系数据库一点也不困难;当开始查看希...
存储
在资源库中存储信息很简单。如果希望存储的信息已经是 XML 格式,那么可以直接把它添加进资源库。这也许听起来不错。毕竟在不断创新的 Web 服务世界中,将要到来的多数信息将使用嵌入在 SOAP 消息中的 XML 片段格式。然而,把 XML 文档分解并保存到关系数据库一点也不困难;当开始查看希望支持的其它功能时,这种作法会有一些好处。同样许多本 Native-XML 数据库供应商所鼓吹的一个好处是 Native-XML 数据库能够存储和查询异种的文档结构。再说,对于结构化数据问题在于:您真的希望信息的结构千变万化吗?对于使用 XML 文档时具有的这种优势,当使用结构化数据时就算不上是一种优势了。

检索
初看上去,从 Native-XML 数据库检索信息似乎也是一个好处:以信息的原始 XML 格式检索它,而不需任何附加的编码,并且可以使信息以一定的样式显示。然而,结构化数据检索的性质使得这种明显的优势实际上变成了劣势。如果信息更新量巨大(例如,接收单个数兆字节大小 XML 文档的股票系统的夜间更新),一些 Native-XML 平台需要从数据库返回整个文档 — 即使您只对文档的很小一部分感兴趣(譬如某个特定股票的变化过程)。 其它 Native-XML 平台在将 XML 文档保存到资源库之前进行分解,但是如果具有复杂的文档结构(正如许多结构化 XML 文档倾向于具有这种结构)时,这样做就显得有点笨拙。无论如何,许多关系数据库供应商目前正在实现瘦 XML 序列化器包装器以便支持在需要时从关系数据生成XML 文档。这使得程序员可以容易地获得完成特定任务所恰好需要的信息,这些信息具有某种格式,这种格式具有所需样式、或者可以发送给其它能识别 XML 的目标。

搜索
搜索 Native-XML 数据库有两种常规解决方法可用,选取哪种取决于数据库供应商。一些 Native-XML 数据库需要选择哪些元素或属性用于索引,如同在关系数据库里选择哪些列用于索引。然后,这个信息被用于建立索引,以便搜索机制能用来快速定位相匹配的文档。在文档被添加到资源库时,其它 Native-XML 数据库就是对文档内的所有信息建索引,可以想象这将导致存储空间需求飞速上升(想象一下在关系数据库中对所有列建索引!)。由于这些数据库以文档为中心的性质,搜索将返回一组 XML 文档;然后如有必要,调用程序还得对这些文档做进一步处理。 很遗憾的是,这意味着更复杂的搜索,是很不方便的。例如,要找出那个对某一特定部分提交最高订单的顾客,以为在中间环节要处理很多事情。在指向关系方面 Native-XML 数据库做的也不好。结果是,如果数据结构不是纯粹层次结构的,则对您而言,Native-XML 数据库就不是恰当的解决方案。大多数 Native-XML 数据库具有这一功效强大的特性 — 执行完善的全文搜索的能力,包括整个同义字支持、字根(匹配一个字的所有形式:现在时、过去时和进行时)以及相近搜索(DTD NEAR XML Schema)。此外,在使用传统文档时,这些特性是不可缺少的,其中上下文在含意上起着重要的作用,而当使用结构化数据时,就远没有那么重要了。
聚合
使用关系数据工作时,聚合是所需要的最重要功能之一,事实上它处于联机分析处理的核心(OLAP)。Native-XML 数据库在执行聚合任务方面表现得特别差。因为信息要么被保持在文档这一层,要么一般被分割成节点,所以把信息汇集起来以及集中处理它(求和、平均数等等)就很困难,此外,还必须在中间环节增加附加代码。如果结构化数据应用程序需要任何一种分析处理 — 我打赌它会需要 — Native-XML 数据库将会使您失望。
 
    
相关主题在前面已经发了两篇文章了。虽然也有不少人阅读(心中窃喜),却罕有评论。甚感遗憾。不管是西红柿还是臭鸡蛋,我都喜欢。很多东西,都是越辨越明的。下面接着写我的一些想法(研究成果说不上,就当想法吧):

    据我分析,现有的native-XML数据库,又过分强调了对XML文档的处理,而忽视了数据库本身的作用:对客观事物的描述和存储。所以在处理传统的关系型数据库所涉及的业务领域,并没有显示出多大的优势,反而会有这样或者那样的不足。
   针对以上的叙述,计划中的XMLDB应该首要实现一下目标(弥补普通数据库的不足和解决一般native-XML数据库的不足):
基于描述的数据库设计,不同于一般数据库的基于数据的数据库设计,或者NXD数据库基于文档的的数据库设计,新的XMLDB,将是基于描述的数据库设计,即,基于对客观事物的描述,充分发挥XML文档在事物描述上的优势,以接近自然语言的方式来存储事物。 
增加版本的概念。能够让不同版本的数据文件协同工作。 
数据分布式存储和强大的聚合能力。最小的储存单位不是XML 储存单元,而是XML DB fragment,可以把同一个表的内容以不同的方式存贮在不同的物理位置,同时对用户透明,利用转换器和聚合器,对用户来说还是一个完整的XMLDBData对象。 
基于多线程的数据检索能力,能够比较迅速的找到所需要的数据内容。利用多线程,可以对一个表的多个XMLDB fragment同时进行检索,然后通过聚合器,聚合成一个完整的XMLDBData对象,实现数据的快速检索。 
支持基于XML的查询语言(XQuery?maybe yes,maybe no)。先实现一个独有的,基于XML的查询方式。在这个基础上,通过转化器,可以同时提供对XQuery,甚至SQL语言的支持 
支持传统数据库里一些基本的概念和功能,比如数据同步,锁的操作,以及事务的操作。这些都是数据库里面一些很经典也很重要的概念,是一个完整的数据库所不可缺少的一部分,应该支持和实现。 
提供完备的Adapter机制,支持对传统SQL语言操作方式的支持。 
提供用户自定义函数功能。先实现用户使用Java语言自定义函数,技术成熟后,提供脚本语言的支持。 
提供多种连接方式和安全解决方案。提供https,Soap等多种网络连接方式,并且数据库本身是一个开放的接口,可以加载不同的安全解决方案。 
提供丰富的连接和调试工具(属于可选目标,除了命令行调试工具外,其他的将不包括在核心组件中)