有何好处?；使用基于XML的数据库的缺点？

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

提前谢谢。

---

Tanmoy

在发现的网络中进行简短查看

主要内容是：“在XML-DEV最近讨论了如何为XML应用程序选择最合适的数据库之后，XML偏差者捕获了有助于您更接近决策的指标。”

这篇文章讨论了“数据”和“文件”的区别

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

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

---

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

只要数据集相对较小，使用XML作为数据库就可以正常工作。Meaining，这一切都可以在记忆中，舒适地停留在那里。一旦您的数据增长到无法全部存储在内存中，您可能会看到严重的性能下降。

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

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

但是，如果您谈论的数据模型需要在SQL中跨3个或4个表进行连接，那么您可能已经接近XPath停止良好扩展的程度。我真的说不出这在其他查询语言（如XQuery或XLinq）中的效果有多好-也许取舍是在另一个地方。

另外，请参阅，以了解为什么“当数据存储在XML中时，无法实现SQL语句SELECT ORTHORM FROM books fast。”

---

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

下次请给出简短的概要并提供链接。然后用自己的话总结k thnxI加粗的要点，而且我只粘贴了相关信息。-1是非常非常不必要的。@Elizabeth包含外部资源的相关部分没有错，即使它们的长度适中。这是正确的归属和明确的。嗨，凯尔，谢谢你的详细回答。这真的很有帮助。但你们知道有哪篇文章是由开源技术专家写的吗？嗨，Tanmoy，很抱歉，但我真的不明白为什么会有不同？本文是针对数据库与平面文件XML的优点而写的。即使MSS