XML and Databases 笔记
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作为数据载体使用的分布式应用程序而言，这个问题不很严重，因为不管用的是哪种数据库，这种前期工作必须要有。