我真的很喜欢Xml来保存数据，但是什么时候sqlite / database成为更好的选择？例如，当xml具有多于x个项目或者大于y MB时？

我正在为rss阅读器进行编码，我相信在sqlite数据库上使用xml来存储所有提要项的缓存时，我做出了错误的选择。有些提要在一个月后的xml文件中会出现〜1mb的提要，另一些提要包含700多个项目，而大多数则只有〜30个项目，并且几个月后的大小约为50kb。

我目前没有实施上限的计划，因为我希望能够搜索所有内容。

因此，我的问题是：

• 什么时候可以通过使用xml来证明sqlite /数据库的开销？
• 当有许多小型xml文件时，尽管即使小型文件也会随着时间增长，但对于这些数据库而言，少数大型xml文件是否足以为数据库辩护？ (很长一段时间)

更新(更多信息)

每次在GUI中选择一个提要时，我都会从该提要xml文件中重新加载所有项目。

我还需要修改已读/未读状态，这在我遍历xml中的所有节点以查找该项目然后将其设置为已读/未读时看起来确实很hacky。

解决方案

回答

对我来说，这实际上取决于我们对他们的处理方式，有多少用户/进程需要同时访问它们，等等。

我一直都在处理大型XML文件，但实际上并不需要它们是单进程，导入样式项，多用户或者性能。

所以确实是一个平衡。

回答

我说这与数据大小无关，而与数据类型有关。如果数据是结构化的，请使用关系数据库。如果数据是半结构化的，请使用XML，或者如果数据量确实太大而无法容纳XML数据库。

回答

我不会使用XML来存储RSS项。提要阅读器在接收数据时会不断进行更新。

使用XML，我们需要首先从文件中加载数据，对其进行解析，然后将其存储以便于搜索/检索/更新。听起来像数据库...

另外，如果应用程序崩溃了怎么办？如果使用XML，则XML文件中的数据与内存中的数据处于什么状态。至少使用SQLite具有原子性，因此可以确保应用程序将以与上一次数据库写入时相同的状态启动。

回答

当我们需要将数据从应用程序移动到其他地方或者在应用程序之间共享信息时，XML最好用作交换格式。对于几乎所有规模的应用程序，数据库应该是首选的存储方法。

回答

如果搜索与数据库。我们可以将xml文件拆分为多个目录以简化查找，但是管理开销很容易变得很重。我们还可以获得不仅仅是sql db的性能...

回答

我同意@Bradley。

XML非常慢，并且作为存储格式不是特别有用。何必？我们将使用文本编辑器手动编辑数据吗？如果是这样，与YAML之类的XML相比，XML仍然不是一种非常方便的格式。使用SQlite之类的东西，查询就更容易编写，并且有一个定义明确的API可用于输入和输出数据。

如果我们需要在程序之间发送数据，那么XML是很好的选择。但是以效率为名，我们可能应该在发送时生成XML，并在接收时将其解析为"真实数据"。

以上所有这些都意味着我们关于"何时证明数据库的开销合理"的问题是没有实际意义的。 XML始终比SQlite具有更高的开销。 (像MSSQL这样的全功能数据库比较重，尤其是在管理开销方面，但这是一个完全不同的问题。)

回答

• 将XML用于应用程序应了解的数据-配置，日志记录以及其他内容。
• 使用数据库(Oracle，SQL Server等)存储用户直接或者间接与之交互的数据-真实数据
• 如果用户数据更多是序列化的集合(例如文件及其内容的巨大列表或者电子邮件项目的集合等)，请使用SQLite。SQLite擅长于此。

取决于数据的种类和大小。

回答

如果需要扩展，请使用数据库。

回答

不要忘记我们拥有一个触手可及的强大数据库：文件系统！

许多程序员忘记了一个不错的目录文件结构是：

• 快如地狱
• 可携带
• 它的运行时占用空间很小

人们正在谈论将XML文件拆分为多个XML文件...我会考虑将XML拆分为多个目录和多个纯文本文件。

搏一搏。令人耳目一新的快速。

回答

XML非常适合用于存储结构不完全的数据，我们通常希望与其他应用程序交换数据。我更喜欢使用SQL数据库存储数据。 XML容易出错，因为数据本身的错字或者遗漏会引起细微的错误。一些开源应用程序框架使用太多的xml文件进行配置，数据等。我更喜欢在SQL中使用它。

既然我们要求经验法则，那么我想说的是，如果我们只打算设置一次而不是大量访问/搜索，请使用基于XML的应用程序数据，配置等。对于主动搜索和更新，最好与SQL一起使用。

例如，Web服务器将应用程序数据存储在XML文件中，而我们实际上并不需要执行复杂的搜索，更新文件。 Web服务器启动，读取xml文件，然后就可以了。因此XML在这里很完美。假设我们使用诸如Struts之类的框架。我们需要使用XML，并且一旦开发和部署了应用程序，操作配置就不会有太大变化。同样，XML文件是一个好方法。现在，如果Struts开发的应用程序允许进行广泛的搜索以及更新，删除，那么SQL是最佳的方法。

当然，我们肯定会遇到组织中的一两个开发人员，他们只会颂XML或者SQL，并宣称XML或者SQL是唯一的选择。当心这样的人，并为应用程序做些"感觉"。不要只是遵循"技术信仰"。

考虑诸如需要多久更新一次数据，多久搜索一次数据之类的事情。然后，我们将获得有关使用XML或者SQL的答案。

回答

我基本上同意Mitchel的观点，这可能是非常具体的，具体取决于我们将对XML / sqlite做什么。对于情况(缓存)，在我看来，使用sqlite(或者其他嵌入式dbs)更有意义。

首先，我真的不认为sqlite比XML需要更多的开销。我的意思是开发时间开销和运行时开销。唯一的问题是我们对sqlite库有依赖性。但是因为无论如何我们都需要一些XML库，所以没关系(我假设项目在C / C ++中)。

sqlite优于xml的优势：

• 一切都在一个文件中，
• 随着缓存的增大，性能损失低于XML，
• 我们可以将Feed元数据与缓存本身(其他表)分开，但是可以通过相同的方式进行访问，
• 对于大多数人来说，SQL可能比XPath更容易使用。

sqlite的缺点：

• 多个进程访问同一个数据库可能会出现问题(可能不是情况)，
• 我们至少应该了解基本的SQL。除非缓存中有成千上万的项目，否则我认为我们无需对其进行太多优化，
• 从安全的角度来看(SQL注入)，也许从某种角度讲可能会更加危险。另一方面，我们不是在对Web应用程序进行编码，因此不应发生这种情况。

对于这两种解决方案，其他方面可能都差不多。

总结一下，分别回答问题：

• 我们将不会知道，除非我们同时使用两个后端测试特定的应用程序。否则，这总是一个猜测。对两个缓存的基本支持应该不是编码的问题。然后进行基准测试并进行比较。
• 由于XML文件的组织方式，sqlite搜索应始终保持更快的速度(除非出现一些极端情况，因为它们的运行速度非常快，所以它们无关紧要)。无论如何，要加快XML搜索速度，就都需要索引数据库，这意味着要为每个缓存使用缓存，并不是一个特别好的主意。但是使用sqlite，我们可以将索引作为数据库的一部分。

回答

XML可以存储为文本和二进制文件格式。

如果主要目标是让计算机有效地读写文件格式，则应使用二进制文件格式。

数据库是一种易于使用的存储和维护数据的方式。
它们不是存储二进制文件格式数据的最快方法。

可以加快速度的是使用内存数据库/数据库类型。 Sqlite具有此选项。

听起来这是为我们做到最好的方法。

回答

我的意见是，当我们不需要纯文本文件格式时，应该使用SQLite(或者其他合适的嵌入式数据库)。注意，这是一个很大的例外。在许多情况下，需要纯文本文件格式或者从中受益。

就开销而言，SQLite可以使用正常标志将其编译为250 k。许多XML解析库都比SQLite大。使用XML不会获得任何并发收益。 SQLite二进制文件格式将支持效率更高的写入(主要是因为我们无法将其添加到格式良好的XML文件的末尾)。即使读取数据(我认为其中的大部分都是相当随机的访问)，使用SQLite也会更快。

最重要的是，我们可以访问SQL的好处，例如事务和索引。

编辑：忘了提。 SQLite的一个好处(与许多数据库相反)是它允许任何列中的任何行中的任何类型。基本上，使用SQLite，就数据类型而言，我们可以获得与XML相同的自由。这也意味着我们不必担心对文本列设置限制。

回答

什么时候应该使用XML而不是数据库来实现数据持久性？几乎从不。 XML是一种数据传输语言。解析和查询很慢。解析XML(不要粉碎它！)，然后将结果数据转换为域对象。然后持久化域对象。持久性数据库的一个主要优点是SQL，这意味着可以进行非结构化查询并可以访问常用工具和优化技术。

回答

我有这个经验吗。我从事的项目是最初使用XML存储所有数据，然后移至sqlite。每种技术都有很多优点和缺点，但是性能是导致切换的原因。这是我们观察到的。

对于小型数据库(几兆或者更少)，XML更快，更易于处理。我们的数据自然采用树形格式，这使XML更具吸引力，并且XPATH允许我们用一条简单的线进行许多查询，而不必走到祖先的树上。

我们在Win32环境中进行编程，并使用了标准的Microsoft DOM库。我们将所有数据加载到内存中，将其解析为dom树，然后在内存副本中搜索，添加，修改。我们将定期保存数据，并且需要旋转副本，以防机器在写入过程中崩溃。

我们还需要使用C ++树形图手动建立一些"索引"。当然，这对于sql来说是微不足道的。

请注意，文件系统上的数据大小比"内存中" dom树小2-4倍。

当数据达到10M-100M大小时，我们开始遇到实际问题。有趣的是，在所有数据大小下，XML处理的速度都比sqlite快得多(因为它在内存中，而不是硬盘中)！问题实际上是双重的，加载时间确实开始变长。我们需要等待一分钟左右，然后数据才能存储在内存中并构建地图。当然，一旦加载程序就非常快。第二个问题是所有这些内存一直都被占用。即使运行速度非常快，只有几百兆的系统也无法在其他应用程序中响应。

我们实际上正在研究使用基于文件系统的xml数据库。有几个开源版本的xml数据库，我们尝试了它们。我从未尝试过使用商业xml数据库，因此无法对其发表评论。不幸的是，我们永远无法使xml数据库完全正常工作。甚至用数百兆的xml填充数据库的行为也要花费数小时....也许我们使用的方式不正确。另一个问题是这些数据库非常重。他们需要Java并具有完整的客户端服务器体系结构。我们放弃了这个想法。

那时候我们找到了sqlite。它解决了我们的问题，但付出了代价。最初插入sqlite时，内存和加载时间问题就消失了。不幸的是，由于所有处理现在都在硬盘驱动器上完成，因此后台处理负荷增加了。之前我们甚至从未注意到CPU负载，但是现在处理器使用率却上升了。我们需要优化代码，仍然需要将一些数据保留在内存中。我们还需要将许多简单的XPATH查询重写为复杂的多查询算法。

因此，这里总结了我们学到的东西。

• 对于树数据，使用XPATH可以更轻松地查询和修改XML。
• 对于小型数据集(少于10M)，XML降低了sqlite的性能。
• 对于大型数据集(大于10M-100M)，XML加载时间和内存使用量成为一个大问题，以致某些计算机无法使用。
• 我们无法获得任何开源xml数据库来解决与大型数据集相关的问题。
• SQLITE不会出现XML dom的内存问题，但是通常处理数据的速度较慢(它在硬盘驱动器上，而不在内存中)。 (注意，sqlite表可以存储在内存中，也许这可以使其速度更快。...我们没有尝试过，因为我们想从内存中取出数据。)
• 在表中存储和查询树数据是不愉快的。但是，管理事务和建立索引可以部分弥补这一点。

回答

我们应该注意，许多大型的关系数据库(Oracle和SQLServer)具有XML数据类型以在数据库中存储数据，并在SQL语句中使用XPath来访问该数据。

同样，有一些本机XML数据库的工作方式与SQLite十分相似，因为它们是一个包含文档集合(可能是一个表)的二进制文件，然后我们可以对单个文档或者整个集合进行XPath / XQuery。因此，使用XML数据库，我们可以执行以下操作，例如将日数据作为单独的XML文档存储在集合中……因此，当我们处理今天的数据时，只需使用该文档即可。但是，编写一个XQuery来找出有关该人的文档集合的历史数据。光滑

我使用了Berkeley XMLDB(现在由Oracle支持)。如果我们在Google上搜索"本地XML数据库"，则还有其他内容。我还没有看到以这种方式存储/检索数据的性能问题。

XQuery是另一种野兽(但值得学习)，但是我们可以仅使用当前使用的XPath进行一些修改。

回答

数据库是我们程序的重要组成部分。如果查询数据是我们业务逻辑的一部分。
XML是最好的文件格式，尤其是如果数据格式是：

1，层次
2，未来可能会以我们无法猜测的方式发生变化
3，数据的寿命比程序更长

回答

我已切换到SQLite，并且知道它在数据库中会更好。

这样做还有很多其他好处：

• 添加新项目真的很简单
• 按多列排序
• 使用唯一索引删除重复项

我已经创建了2个视图，一个用于未读项目，一个用于所有项目，不确定这是否是视图的最佳用法，但我确实想尝试使用它们。

我还使用StopWatch类对xml vs sqlite进行了基准测试，并且sqlite更快，尽管这可能只是我解析xml文件的方式并不是最快的方法。

• 约8.0毫秒xml
• 〜25毫秒xml
• 约60毫秒的XML