使用XML来进行数据传输是很好的方案，因为数据具有高度规范的结构，而XML中的那些实体和编码并不重要。毕竟我们关心的仅仅是数据而不在于这些数据如何在文档中进行物理的存储。如果应用程序相对比较简单，关系数据库和数据传输中间件就可以满足需求；如果应用程序庞大而且复杂，那么就需要一个完全支持XML的开发环境。
从另一方面来说，假设有一个从零散的XML文件创建的网站，不仅需要管理这个网站，还要提供方法让用户可以查询其中的内容，这时网站的文件将非常的不规范，而这些文件的使用却变得非常重要，因为这些文件的结构是网站的根本。
要存储或检索数据，可以使用一个数据库（通常是关系型、面向对象型或者是层次型）和中间件（自带或者是采用第二方）,也可以使用XML服务器（即创建分布式应用的平台，例如利用XML进行数据传输的电子商务应用）。
在选择数据库时，最重要的判断因素可能是你是利用数据库来保存数据还是保存文档。如果想保存数据，那么需要的数据库主要是面向数据存储（例如关系型数据库或者面向对象型数据库）以及在数据库和XML文档之间相互转换。
在以数据为中心的文档中的数据内容可能来自数据库（此时想把数据导出为XML格式）,也可能是XML文档（此时想把数据存储在数据库中）。前者的例子是在关系型数据库中存储的大量现有数据（或称遗产数据）；后者的例子是将数据作为XML发布在Web中，而且要在你的数据库中进行存储以进行更多的处理。因此，根据需求，可能需要将XML文档转移到数据库的软件，也可能需要从数据库转移到XML文档的软件，或者两者都支持。
将数据存储在数据库中时，经常需要丢弃大量与文档有关的信息，例如文档名称，同时还有其物理结构，例如实体的定义和使用、属性值和同层元素的顺序、二进制数据的存储方式、字符数据段和其他的编码信息。类似的，当从数据库中检索数据时，生成的XML文档结果除了非预定义实体，不包含任何字符数据或实体引用。而同层元素和属性的出现顺序也常常就是从数据库中返回的数据的次序。
这一般是合理的。例如，假设需要用XML作为数据格式把一张销售单从一个数据库中转移到另一个数据库中。在这种情况下，在XML文档中并不关心销售单的编号是保存在销售单的日期的前面还是后面，也不用关心是否将顾客的名称保存在字符数据段还是作为一个外部实体。最重要的在于相关的数据是从第一个数据库转移到第二个数据库中。这样，这个数据传输软件就需要考虑数据的层次结构（该结构将销售单的有关数据进行了分组），而其他则不必过多考虑。
文档的“逆反回归"的不一致效应，即将一个文档的数据存储在数据库中，然后根据这些数据重新组织成新的文档。而即便是根据标准格式处理，得到的也常常是和前面不同的文档。
这是否可以接受要取决于你的需求，而且也将影响到你对数据库和数据传输中间件的选择。
为了在XML和数据库之间传输数据，需要在文档结构和数据库结构之间进行相互的映射。
这样的映射通常分为两大类：模板驱动和模型驱动
在以模板驱动的映射中，没有预先定义文档结构和数据库结构之间的映射关系，而是使用将命令语句内嵌入模板的方法，让数据传输中间件来处理该模板。
在以模型驱动的映射中，利用XML文档结构对应的数据模型显式或隐式地将其映射成数据库的结构，而且反之亦然。它的缺点是灵活性不够，但是却简单易用，这是因为它是基于具体的数据模型来进行映射的，通常能够为用户实现很多的转换工作。由于将数据从数据库转换成XML的结果依照了单个模型，因此在这种方式下通常结合XSL来提供模板驱动的系统中所具有的灵活性。在XML文档中的数据视图通常有两种模型：表格模型和特定数据对象模型。
有时候也可能会出现其他的模型。例如，通过采用ID和IDREF属性，一个XML文档可以用来表示一个指定的图形。不过，很多现有的中间件并不支持这些模型。
1）表格模型
许多中间件软件包都采用表格模型在XML和关系型数据库之间进行转换。它把XML的模型看成是一个单独的表格或者是一系列的表格。也就是说，XML的文档的结构和下面的例子相类似，其中在单个表格的情况下，〈database〉并不出现。
<database>
<table>
<row>
<columnl>. . . </coluinnl>
<column2>...</column2>
</row>
</table>
</database>
其中的术语“table”可理解为单个的结果集《当从数据库向XML中转换数据时），或者是一个单独的表格或可更新的视图（当从XML向数据库转换数据时）。如果数据需要来自多个结果集（当数据来自数据库中时）或者与仅仅表达成一系列表格的集合（当转换数据到数据库时）相比，XML的文档包含有更深层次的嵌套元素，那么类以的转换几乎是不可能的。
2）特定数据对象模型
XML文档中第二种普遍的数据模型是特定数据对象的树型结构。在该模型中，元素类型通常对应对象，而XML中的内容模型、属性和PCDATA则对应对象的属性。这种模型直接映射成面向对象的数据库和层次型数据库，当然借助于传统的对象-关系映射技术和SQL对象视图也可以映射成关系数据库。要注意的是，这种模型并不是文档对象模型（DOM）。DOM是对文档本身进行建模，而不是对文档中的数据。
在XML和数据库进行数据转换时，需要考虑许多问题。XML不支持任何有实际意义的数据类型。所有XML文档中的数据都被当成文本来对待，即便它能够用其他的数据类型（如日期或者整数）来表示。通常，数据转换中间件将把XML文档中的文本转换成其他数据库中的数据类型，反之亦然。然而，特定的数据类型所识别的文本格式是有限制的，例如受到提供的JDBC Driver所支持的数据类型的限制。在这些众多的数据类型中，日期类型通常会导致麻烦。
不同国际地区的数字格式的差异也可能产生问题。
在数据库世界中，空值（null）数据意味着数据不存在值.但是这与一个值为0的数字或长度为0的字符串有很大的区别。例如，假设你的数据来自一个气象站，如果气象站的温度计出了故障读不出温度值，那么你的数据库中将存储一个null值而不是一个0。XML中空值概念的支持可以通过设置可选的元素类型或属性来实现。如果元素类型或属性值为null, XML只要在文档不包含该元素或者属性就可以了。但是对数据库而言，空的元素或包含长度为零的字符串属性并不是空值null,它们的值为长度为0的字符串。在XML文档和数据库结构之间相互映射过程中，你必须特别注意那些可选的元素类型或属性是否对应于数据库中的空值项.
如果不这么做的话，很可能出现插入错误（当将数据转换到数据库中时）或者无效文档错误（当将数据从数据库读出时）=因为同样要用符号表示空值，XML中相对于数据库而言更为灵活。具体来讲，许多XML用户很可能包含空字符串的空元素或属性是空值，这个时候你必须考虑如何选择合适的中间件来解决这个问题。一些中间件可以让用户选择在XML文档中定义用什么来组成空值。除了一些控制字符，XML文档能够包含任何的Unicode字符。但许多数据库都限制或者不支持Unicode,而且需要一些特殊的配置才能够处理非ASCII编码的字符数据。如果你的数据包含了非ASCII字符，那么务必要核实你的数据库和中间件是否能够处理这些字符。