| 使用XML来进行数据传输是很好的方案，因为数据具有高度规范的结构，而XML中的那些实体和编码并不重要。毕竟我们关心的仅仅是数据而不在于这些数据如何在文档中进行物理的存储。如果应用程序相对比较简单，关系数据库和数据传输中间件就可以满足需求；如果应用程序庞大而且复杂，那么就需要一个完全支持XML的开发环境。
|
|
|
| 从另一方面来说，假设有一个从零散的XML文件创建的网站，不仅需要管理这个网站，还要提供方法让用户可以查询其中的内容，这时网站的文件将非常的不规范，而这些文件的使用却变得非常重要，因为这些文件的结构是网站的根本。
|
|
|
| 要存储或检索数据，可以使用一个数据库（通常是关系型、面向对象型或者是层次型）和中间件（自带或者是采用第三方），也可以使用XML服务器（即创建分布式应用的平台，例如利用XML进行数据传输的电子商务应用）。
|
|
|
| 在选择数据库时，最重要的判断因素可能是你是利用数据库来保存数据还是保存文档。如果想保存数据，那么需要的数据库主要是面向数据存储（例如关系型数据库或者面向对象型数据库）以及在数据库和XML文档之间相互转换。
|
|
|
| 在以数据为中心的文档中的数据内容可能来自数据库（此时想把数据导出为XML格式），也可能是XML文档（此时想把数据存储在数据库中）。前者的例子是在关系型数据库中存储的大量现有数据（或称遗产数据）；后者的例子是将数据作为XML发布在Web中，而且要在你的数据库中进行存储以进行更多的处理。因此，根据需求，可能需要将XML文档转移到数据库的软件，也可能需要从数据库转移到XML文档的软件，或者两者都支持。
|
|
|
| 将数据存储在数据库中时，经常需要丢弃大量与文档有关的信息，例如文档名称，同时还有其物理结构，例如实体的定义和使用、属性值和同层元素的顺序、二进制数据的存储方式、字符数据段和其他的编码信息。类似的，当从数据库中检索数据时，生成的XML文档结果除了非预定义实体，不包含任何字符数据或实体引用。而同层元素和属性的出现顺序也常常就是从数据库中返回的数据的次序。
|
|
|
| 这一般是合理的。例如，假设需要用XML作为数据格式把一张销售单从一个数据库中转移到另一个数据库中。在这种情况下，在XML文档中并不关心销售单的编号是保存在销售单的日期的前面还是后面，也不用关心是否将顾客的名称保存在字符数据段还是作为一个外部实体。最重要的在于相关的数据是从第一个数据库转移到第二个数据库中。这样，这个数据传输软件就需要考虑数据的层次结构（该结构将销售单的有关数据进行了分组），而其他则不必过多考虑。
|
|
|
| 文档的“逆反回归”的不一致效应，即将一个文档的数据存储在数据库中，然后根据这些数据重新组织成新的文档。而即便是根据标准格式处理，得到的也常常是和前面不同的文档。这是否可以接受要取决于你的需求，而且也将影响到你对数据库和数据传输中间件的选择。
|
|
|
| 为了在XML和数据库之间传输数据，需要在文档结构和数据库结构之间进行相互的映射。这样的映射通常分为两大类：模板驱动和模型驱动。
|
|
|
| 在以模板驱动的映射中，没有预先定义文档结构和数据库结构之间的映射关系，而是使用将命令语句内嵌入模板的方法，让数据传输中间件来处理该模板。例如，考虑下面的模板，在元素中内嵌了SELECT语句：
|
|
|
|
|
| 当数据传输中间件处理到该文档时，每个SELECT语句都将被各自的执行结果所替换，得到下面的XML格式：
|
|
|
|
|
| 这种以模板驱动的映射可以相当的灵活。例如，有些产品可以允许你在任何结果集合中替换你想要的内容（包括在SELECT中使用参数），而不是像上面的例子中简单地格式化结果。另外它还支持使用编程来进行构造，例如循环和条件判断结构。还有一些支持SELECT语句的参数化，例如通过HTTP来传递参数。目前，以模板驱动的映射只支持从一个关系型数据库转换成XML文档的情况。
|
|
|
| 在以模型驱动的映射中，利用XML文档结构对应的数据模型显式或隐式地将其映射成数据库的结构，而且反之亦然。它的缺点是灵活性不够，但是却简单易用，这是因为它是基于具体的数据模型来进行映射的，通常能够为用户实现很多的转换工作。由于将数据从数据库转换成XML的结果依照了单个模型，因此在这种方式下通常结合XSL来提供模板驱动的系统中所具有的灵活性。在XML文档中的数据视图通常有两种模型：表格模型和特定数据对象模型。有时候也可能会出现其他的模型。例如，通过采用ID和IDREF属性，一个XML文档可以用来表示一个指定的图形。不过，很多现有的中间件并不支持这些模型。
|
|
|
