使用基于 XML 的数据库有哪些优点和缺点？答案

【问题标题】：What are the advantages & disadvantages of using XML based database?使用基于 XML 的数据库有哪些优点和缺点？
【发布时间】：2010-11-30 15:40:54
【问题描述】：

我遇到了一个名为 GetSimple 的 CMS。它使用 XML 存储其所有内部数据。在某种程度上，它使用 XML 作为数据库。现在谁能解释一下使用 XML 作为数据库的优缺点。

提前致谢。坦莫伊

【问题讨论】：

标签： xml database content-management-system

【解决方案1】：

Some information, Quoted from this site:

如果您的应用程序需要在企业之间移动数据，XML 是一个很好的解决方案。 XML 允许您使用标准 HTTP 协议通过 Internet 和防火墙发送数据。如果您的应用程序需要在硬件或软件平台 (OS) 之间移动数据，XML 也是一个不错的选择。 XML 不是特定于机器或操作系统的。最后，如果您只是想确保您的应用程序或数据源在数据架构发生变化的情况下仍然健壮，那么 XML 是一个不错的选择。 XML 使您的应用程序具有可扩展性，因为您通过使用元素和属性名称而不是结构化编程语言使用的偏移量来访问 XML 格式的数据。请注意，使用元素和属性名称访问 XML 中的数据类似于在 SQL Server 表中按名称访问字段。如果您有这些应用程序需求中的一个或多个，那么 XML 对您来说是一个很好的解决方案。

接下来，您需要确定在应用程序中生成或使用 XML 的最佳位置，这是一个重要的决定，因为使用 XML 会产生处理开销。这种开销以不同的方式表现出来，具体取决于您是使用还是生成 XML。对于 XML 使用者，您至少需要一种方法来解析 XML。您可能还需要一个对象模型来访问已解析的数据。对于 XML 生产者，将本机数据格式转换为 XML 会产生开销。在中间层，处理开销至关重要。 如果您的中间层程序对数据进行操作、计算或重新格式化，并且您的数据库位于防火墙内，那么 XML 不应该是您的首选。在这种情况下，从数据库请求一个正常的结果集并使用传统的数据访问方法来执行应用程序处理会更有效。处理完成后，中间层应用程序可以生成 XML 输出。使用传统的数据访问方法避免了在数据库中生成 XML 的开销以及解析 XML 和在中间层构建对象模型的开销。 在中间层生成 XML 的唯一潜在好处是您可以松散地耦合中间层应用程序和数据库，但成本很高。

现在，让我们将这些使用指南应用于您在问题中描述的场景。您似乎不需要在企业之间、通过 Internet 或通过防火墙移动数据。 因此，除非您试图使您的应用程序更具可扩展性，否则 XML 不是您的方案的好选择。传统的数据访问技术将满足您的需求。但是为了展示 XML 的价值，我们假设您需要使您的应用程序可扩展。您可以升级到 SQL Server 2000 并使用其集成的 XML 支持。这是您的最佳选择，因为它提供了最大的灵活性。如果您必须从 SQL Server 7.0 或 6.5 访问您的数据，请查看http://msdn.microsoft.com/downloads/samples/internet/xml/sqlxml/default.asp 的 SQL Server XML 技术预览。此预览版提供的功能类似于 SQL Server 2000 中的 XML 支持，但该预览版适用于 SQL Server 7.0 和 6.5。（有关 SQL Server 2000 的 XML 集成与 Microsoft 的 XML 技术预览之间的差异的信息，请参阅 Bob Beauchemin，“The XML Files”，2000 年 9 月。）

【讨论】：

下次给出一个简短的概要并提供一个链接。然后用你自己的话总结一下k thnx
我把要点加粗了，也只贴了相关信息。 -1 非常非常不必要。
@Elizabeth 包含外部资源的相关部分并没有错，即使它们的长度适中。它是正确归属和明确的。
嗨凯尔，感谢您的详细回答。这真的很有帮助。但是你知道开源技术专家写的任何文章吗？
嗨 Tanmoy，我很抱歉，但我真的不明白为什么这会有所作为？这篇文章是针对数据库与平面文件 XML 的优点而写的。尽管 MSSQL 被命名为替代方案，但它仍然只是 XML 与 DB 之间的比较。

【解决方案2】：

只要您的数据集相对较小，使用 XML 作为数据库就可以正常工作。意思是，它都可以放在记忆中并舒适地呆在那里。一旦您的数据增长到无法全部放入内存的程度，您可能会开始看到严重的性能下降。

【讨论】：

你好 baldy，确实可能会发生性能下降，但你知道有多少数据可以聚合到 XML 数据库中吗？
老实说，在您填满记忆之前很久，您就会开始看到效率低下的查询。许多 XML 或平面文件数据库在超过 20 或 30 兆时会开始变慢，具体取决于您的数据结构。
MarkLogic 服务器（一个原生 XML 数据库）可以处理数百 TB，而 eXist（一个开源原生 XML 数据库可以处理数百 GB 到 1 TB。文件大小并不重要，因为所有 xml 都被索引和存储在持久性 DOM 中。因此，超过数百 GB 的 XQuery 很容易成为亚秒级查询。

【解决方案3】：

在网络中找到this article on XML.com

引言是：'在最近一次关于如何为您的 XML 应用程序选择最合适的数据库的 XML-DEV 讨论之后，XML-Deviant 捕获了有助于使您更接近决策的指标。

文章讲了“数据”和“文档”的区别。

【讨论】：

【解决方案4】：

实际上 XML 文档已经是数据库，无论您使用 DOM、SAX、Pull 或 VTD-XML 做什么，在存储到数据库之后您仍然需要做...在我看来，这或多或少是一个视角的改变

【讨论】：

为什么不是社区维基？我真的不知道它首先是为了什么

【解决方案5】：

我认为这还取决于您查询的复杂性。如果您对编写 XPath 查询相当满意，那么即使您必须跨几个“维度”查询数据，您仍然可以使用相当不可怕的 XPath 代码。

但是，如果您谈论的是需要在 SQL 中连接 3 或 4 个表的数据模型，那么您可能已经接近 XPath 停止扩展的地步了。我真的不能说这与 XQuery 或 Xlinq 等其他查询语言的效果如何 - 也许权衡是在不同的地方。

【讨论】：

【解决方案6】：

另外，请参阅http://www.joelonsoftware.com/articles/fog0000000319.html，了解“当您的数据以 XML 形式存储时，您无法快速实现 SQL 语句 SELECT author FROM books”。

（“快”是这里的关键词）

【讨论】：