使用XML作为数据存储[关闭]

我在考虑XML格式和以下引号：

“ XML不是数据库。它从来都不是一个数据库。它永远不会成为数据库。关系数据库是经过验证的技术，具有20多年的实施经验。它们是坚固，稳定，有用的产品。他们不会消失。XML是在不同数据库之间或数据库与其他程序之间移动数据的非常有用的技术。但是，它本身不是数据库。“不要像以前一样使用它。”- Elliotte Rusty Harold着，有效的XML：50种改进XML的特定方法（第230页，第4部分，第41项，第二段）

这似乎确实强调了XML不应该用于数据存储，而应该仅用于程序之间的互操作性。

我个人不同意，app.config用于存储程序设置的.NET 文件是XML文件中数据存储的一个示例。但是，对于数据库而不是配置等，不应使用XML。

为了
阐明我的观点，我将使用两个示例：A）有关客户的数据全部都在一个级别上，即，有许多字段都与一位没有子
级的客户有关B）有关应用程序配置的数据，其中嵌套字段和属性很有意义

所以我的问题是，这仍然是有效的语句吗？现在可以接受使用XML存储数据了吗？

编辑：我已经给该报价的作者发送了一封电子邮件，要求他提供输入/其他上下文。

该引用不是关于将XML通常用作存储格式（根据需求可以使用XML），而是用于数据库类型的存储。

当人们谈论的数据库存储，他们通常是指存储系统庞大的数据量，往往在GB或TB级。数据库可能比存储它的服务器上的可用RAM容量大得多。由于没有人一次需要数据库中的所有数据，因此应该优化数据库以快速检索其数据的选择性子集：这就是SELECT声明的目的，而关系数据库以及NoSQL解决方案可以快速优化其内部存储格式检索此类子集。

但是，XML并不真正符合这些要求。由于其嵌套标签结构，如果不遍历整个文档树（至少直到匹配项），就无法确定某个值在文件中的何处存储（就文件中的字节偏移而言）。关系数据库具有索引，即使使用原始的二进制搜索实现，在索引中查找值也是一次O（log n）查找，然后获取实际值只不过是文件查找（例如fseek(data_file_handle, row_index * row_size)），即O（1）。在XML文件中，最有效的方法是在文档上运行SAX解析器，在获取实际数据之前进行了大量的读取和查找。除非使用索引，否则您很难获得比O（n）更好的结果，但是随后，您必须为每次插入都重建整个索引（请参见下文）。

插入甚至更糟。关系数据库不保证行顺序，这意味着它们只能追加新行，或覆盖任何标记为“已删除”的行。这非常快：DB只能在周围保留可写位置池；除非池为空，否则从池中获取条目为O（1）；最坏的情况是，该池为空，必须创建一个新页面，但这也是O（1）。相比之下，基于XML的数据库将必须将所有内容移动到插入点之后才能腾出空间；这是O（n）。当索引开始起作用时，事情将变得更加有趣：典型的关系数据库索引可以以相对较低的复杂性进行更新，例如O（log n）；但是如果要索引XML文件，则每次插入都可能会更改文档中每个值在磁盘上的位置，因此您必须重建整个索引。这也适用于更新，因为更新（例如，元素的文本内容）可以更改其大小，这意味着连续的XML必须移动。如果更新未索引的列，则关系数据库完全不需要接触索引；一个XML数据库将必须为每次更新重建整个索引，以更改更新的XML节点的大小。

这些是最重要的缺点，但还有更多。XML非常冗长，非常适合服务器到服务器的通信，因为它增加了安全性（接收服务器可以对XML执行各种完整性检查，并且如果传输中出现任何错误，则文档不太可能通过验证）。但是，对于大容量存储而言，这是致命的：XML数据具有100％或更多的开销并不罕见（对于SOAP消息之类的开销比率在1000％范围内并不少见），而典型的关系数据库存储方案的表元数据只有恒定的开销，每行只有一点点；关系数据库中的大部分开销都来自固定的列宽。如果您有TB级的数据，出于许多原因，500％的开销根本是不可接受的。

XML对于数据存储而言很糟糕。首先，它非常冗长。与任何合理的数据库系统中存储的相同数据相比，存储在XML文件中的数据将占用更多的磁盘空间。在XML记录中，特定字段的名称将与数据的字符串表示形式一起存储两次。因此，例如，要将一个整数存储在一个名为“ foobar”的字段中，您将得到以下19个字节的字符串：

<foobar>42</foobar>

另一方面，真实的数据库会将其存储为单个整数值，占用4个字节。如果您的数据库很小，那并不意味着什么，但是如果您有10,000条记录，那就是一个问题。

其次，每次读取文件时都必须从文本中解析XML。对于上面的字段，真实的数据库只是将二进制数据从它知道将字段“ foobar”存储在其中的偏移量中读取到内存中。如果文件存储为XML，则它必须读取字段“ foobar”并解析该文本，确定它是哪个字段，然后解析字符串“ 42”并将其转换为二进制文件42。

因此，使用XML的性能损失很大。XML的好处是它在某种程度上是人类可读的，并且允许在完全独立的系统之间轻松地传输数据。这些优点均不适用于本地数据库。

一个例外是配置文件，该文件通常很小，并且通常需要人工编辑。

一个XML数据库绝对会比任何合理的SQL系统更大，更慢。除非您发现在人类可读性或互操作性方面的平衡优势，否则将其用于数据存储毫无意义。

XML是否可行取决于上下文。如果您的数据非常静态，并且变化不大（例如，示例数据），那么XML是一个很好的用法。

配置设置，示例数据（即使是数百万行，但很少更改）都是XML的良好用法。

硬盘读/写很昂贵，比从Oracle / Sql堆栈访问数据要贵得多。

这似乎确实强调了XML不应该用于数据存储，而应该仅用于程序之间的互操作性。

您的前提有缺陷。

您引用的段落实际上是在说XML并不是数据库的替代品，并不是说XML不应该用于数据存储。

显然，设置文件与数据库不是同一个人，因此可以（并且应该使用）不同的技术。

如果我错了，请纠正我，但是您似乎比数据库拥有更多的标记语言经验。如果您对数据库有一定的经验，您会意识到两种不同技术都适用于哪些领域。

这真的是主观的。那句话就像别人的看法一样。

老实说，我认为XML是一种可行的替代数据库的方法，因为它比RDMS具有多个优点，包括开销低，这意味着更便宜的存储（尤其是在使用对数据库单独收费的托管服务时）。

看一下dasBlog和BlogEngine。这两个应用程序均默认使用xml进行存储。

那就是。它不是RDMS，并且如果您的数据具有高波动性（大量更新，插入或删除操作）或需要高可用性，请使用数据库。XML非常适合存储诸如配置数据和低挥发性数据之类的小东西。

我的问题是，这仍然是有效的语句吗？现在可以接受使用XML存储数据了吗？

我在您有关.NET配置文件的示例中看到了您的观点。但是，可以使用任何其他文件格式。实际上，在过去，此类设置曾经存储在称为INI文件的常规文本文件中。

我看到，如果将数据库定义为软件系统，则以灰色显示的陈述是正确和正确的。

XML-Definition中XML的定义 指出：“（XML）是一种标记语言，它定义了一组用于以人类可读和机器可读的格式编码文档的规则。”

该定义侧重于可读性和语言，而不是管理数据的机制。

与RDBMS相比，XML不提供随机插入和删除XML文件中的行的方法。例如，如果您有1000000行，并且希望即使在单个用户环境中也要随机删除行，则对于数据库而言，基于XML的文件不是一个好的选择。而且，XML不提供任何用于锁定数据的本机机制。实际上，由于XML并非软件，因此保证在共享环境中可靠地处理数据库事务的所有ACID（原子性，一致性，隔离性，持久性）属性都由开发人员来构建（耐久性）。XML没有强大的规范来处理XML文件之间的数据完整性，更不用说不同的服务器了（例如，客户xml文件和订单xml文件-没有用于强制完整性的FK）。

以上并不是对XML缺乏的一种列举，相反，它可以作为XML不是数据库软件的陈述的快速证明。

XML绝不意味着要成为数据库或取代它。

XML主要是为Web文档定义的，allows for the creation of customized tags for individual information fields.但是，您将永远无法使用XML 实现关系集中式数据管理。

您实际上为什么首先要使用XML来存储数据？我的意思是，毕竟这是一门语言 ...

虽然有人可能会说这是一种灵活且易于理解的格式，但仅在您必须手动编辑文件时才适用。当您实际使用具有公共接口的数据库进行交互时（获取满足要求Y和Z的数据X，存储/更新数据X，...），这些优点将变得无效。

简短的回答：这取决于。

长答案：从我的角度来看，这在很大程度上取决于您要存储的数据量。例如，如果在运行时您的应用程序中有几个对象，并且您希望在运行该工具后将它们存储，那么XML文件就可以了。但是，如果您的网上商店有5000名客户，甚至更多的订单，数据库将是更合适的数据存储。

另外，我认为在大多数情况下，将设置存储在数据库中而不是像app.config这样的文件中并不是很有用，但是我不认为该示例证明了引号是错误的。

XML是配置设置的绝佳选择。XML文件不仅易于在IDE中解析/突出显示，而且非程序员也很容易编辑。我发现它们在设计人员和内容管理员正在执行维护任务的Web开发场景中非常有用。

XML通常不应用作任何非平凡应用程序的主要数据源。单独的序列化/反序列化开销要求不同的解决方案。

术语数据库既可以指原始数据，也可以指数据库管理系统。此定义在整个参数上有很大的不同。

如果我们使用RDBMS定义，那么XML在这种意义上几乎没有。在ACID保证方面，您获得的很少（您必须编写自己的代码才能完成这些工作）。如果您需要这些（大多数事务系统都需要），那么您已经遇到了大麻烦。我可以列出RDBMSes理所当然的数百种功能，您必须重新发明和重新实现这些功能。考虑安全模型，复制，备份，仅举几个基本模型。

从上述意义上讲，不，XML不是数据库，您不应该尝试将其用作数据库。

如果使用“原始数据”定义，则XML的性能要好很多，但仍然不那么好。但是，正如其他人指出的那样，它通常非常冗长，通常缺少二进制编码，并且具有重复的标签等。这些折衷是为了使XML可以被人类阅读-基本上，效率是此要求的敌人。XML也不是特别适合连续插入记录的最简单情况。假设您希望XML文件有效，则需要一个结束标记，这意味着追加记录意味着您需要在末尾将标记上移。这是非常昂贵的（我们如何知道该标记从哪里开始？如果有多个“表”，我们只是将整个文件向上移动？），如果您要解决它，您会

在某些情况下，XML是合适的-配置文件就是一个很好的例子，因为配置文件通常很小，并且人类可读性是它的一项出色功能。只为一个配置文件拥有一个数据库可能是过大的选择。

另一方面，当您有成千上万（或数百万/十亿）条记录，并且有许多用户同时更新它们时，数据库非常有用。所以是的，XML不是数据库，您不应该像使用它那样使用它。您的示例碰巧是其中一开始不需要DB的情况之一，而XML更适合。

我的看法是这样的： 如果将XML用作数据库（例如，作为事务系统的后备存储），那么最终将重新发明并重写RDBMS。那是浪费时间和精力的一种非常糟糕的方法。我认为这也是那句话的意思。

我同意这不是关系数据库。我认为作者只是在引文中说不要将其用作一个。

话虽如此，尽管您可能需要也可能不需要。如果您实际上不需要对数据进行大量查询，而仅打算存储数据，然后根据一些有限的查询条件稍后再获取数据，则您需要XML DOCUMENT存储和检索-而不是关系数据库。

有许多应用程序只需要存储文档和数据即可在以后进行整体检索。如果是这种情况，那么创建基于SQL的架构，解析XML，然后将其序列化到数据库中就没有用了，以后再做就可以了。这样做可能涉及很多代码开销。如果您做对了，那就更少了。

您可以使用Hibernate之类的ORM工具和Apache Axis之类的工具，以便实际上自动生成构建只处理简单CRU操作的服务所需的所有代码。当然，您必须将其包装在身份验证中，并且可能可能想根据用户，访问级别等来分离数据。您甚至可能想要限制允许给定用户通过SOAP服务执行的操作例。

从这个意义上讲，您比其他任何事情都更像内容管理。