XML and Databases 笔记

作为一种“数据库”格式,XML有一些优势:例如,它是自描述的(所用的标记描述了数据的结构和类型,尽管缺乏语义),可交换的(portable),能够以树型或图形结构描述数据。同样它也有缺点,例如,它显得有些繁琐,由于要对它进行解析和文本转换,所以数据访问速度较慢。

XML及其周边技术是否可以算作“数据库” -- 数据库管理系统(DBMS)。答案是“在某种程度上是(sort of)”。好的一面是,XML提供了许多数据库所具备的东西:存储(XML文档), 模式(DTD, XML schema,RElAX NG 等等), 查询语言(XQuery, XPath, XQL, XML-QL, QUILT等等),编程接口(SAX, DOM,JDOM)等等。不好的一面在于,它缺少一些作为实用的数据库所应具备的特性:高效的存储,索引,安全,事务和数据一致性,多用户访问,触发器,在查询多个文件等等。

因此,尽管在数据量小、用户少和性能要求不太高的环境下,可以将XML文档用作数据库,但是却不适用于用户量大、数据完整性以及性能要求高的情形。

将一个XML文件的schema映射到数据库的schema有两种方法:基于表格的映射对象-关系映射

基于表格的映射把XML文件看作一个(或一组)表格,将各字段数据以子元素的形式或以属性的形式存储。

基于表格的映射对存取关系型数据比较适用,比如在两个关系型数据库之间转换数据。其明显不足就是不适于格式不符的XML文件。
对象-关系的映射方式将XML文件中的数据视为特定的对象树的模型。在这个模型中,元素及其类型、元素内容或混合内容( 复合元素类型)通常被视为类。只具有PCDATA内容的元素( 简单元素类型)、属性以及PCDATA都被当作简单属性。然后通过传统的对象-关系映射技术或 SQL 3的对象视图将该模型映射到关系型数据库。也就是说,类被映射到表格,简单属性被映射到字段,而值为对象属性被映射为成对的主键/外键(primary key/foreign key)。

原生XML数据库的数据存储

还可以将XML文件中的数据存储在原生XML数据库(native XML database)中。这么做有几个理由。首先,当你的数据是半结构化的数据时。也就是说,它的结构是普通的,但是如果将其映射到关系数据库,结果是要么出现大量空值(null)的字段,要么表格的数量过多,浪费空间或效率低下。虽然半结构化的数据可存储到面向对象的或层次型数据库中,你还可以选择将它以XML文件的形式存储于原生XML数据库。

将数据存储在原生XML数据库中的第二个理由是读出速度。根据XML数据库存储数据的物理方式的不同,数据的读出速度可以做到比关系型数据库[的读取速度]快得多。其原因是,原生XML数据库对整个文件一起进行物理存储,和[表示]文件各个部分的物理(而不是逻辑)指针可采用同一存储策略。这就可以不使用连接(joins)或只使用物理连接读取文件,无论哪种情况都比关系型数据库所用的逻辑联结要快。

以上述销售订单文件为例。在关系型数据库中,它可能被存为四个表格 -- SalesOrders, Items, Customers, 和 Parts -- 读取文件时需要将这些表格结合起来。在原生XML数据库中,整个文件可被存储在磁盘的一个地方,在读取文件或其片断时只需要一次查找和一次读取操作。关系数据库在读取数据时则需要四次查找以及至少四次读取操作。

这样做的一个明显缺点就是,只有数据的读取顺序和写入磁盘的顺序相同时,才可以提高速度。如果你想要的数据视图不同,比如只想要客户及其订单列表,性能可能比关系数据库更差。所以,如果你的应用中是单个数据视图为主,为了提高性能,才可以考虑将数据存储到原生XML数据库。

将数据存储在原生XML数据库中的第三个理由是你想利用XML的独有特性,如执行XML查询。由于今天以数据为中心的应用几乎没有这样做的,而且关系数据库正在逐步支持XML查询语言,这个理由越来越不充分。

将数据存储在原生XML数据库中的一个问题是,大多数原生数据库只能以XML[的形式]返回数据。(支持元素和属性到应用程序变量绑定的只是少数)。如果你的应用程序需要另一种数据格式(很有可能),使用数据之前必须先解析XML。对本地的应用程序而言显然是个缺点,而这种前期准备在(比如)ODBC中就不存在。对于将XML作为数据载体使用的分布式应用程序而言,这个问题不很严重,因为不管用的是哪种数据库,这种前期工作必须要有。


你可能感兴趣的:(XML and Databases 笔记)