我编码一个RSS阅读器，我相信我错误的选择使用xml在sqlite数据库存储所有订阅源项目的缓存。有一些Feed有一个〜1mb一个月的xml文件，另一个有700多个项目，而大多数只有〜30项，几个月后大小约50kb。
我目前没有计划实施上限，因为我喜欢能够搜索一切。
所以，我的问题是：
>什么时候sqlite /数据库的开销通过使用xml？
>几个大型的xml文件对于数据库来说足够多，当有很多小的数据库时，虽然小的数据库会随着时间的推移而增长？ (长时间长)
更新(更多信息)
每次在GUI中选择一个订阅源时，我会重新加载来自该订阅源xml文件的所有项目。
我还需要修改读/未读状态，当我循环遍历xml中的所有节点，找到该项，然后将其设置为读/未读似乎真的hacky。
首先我不认为sqlite将需要比XML更多的开销。我的意思是开发时间开销和运行时开销。只有问题是你有依赖sqlite库。但是因为你需要一些XML库，无论如何它没有关系(我认为项目是在C/C++)。
sqlite对xml的优点：
>一切都在一个文件，
>性能损失低于XML缓存越来越大，
>您可以将Feed元数据与缓存本身(其他表)分开，但可以以相同的方式访问，
>对于大多数人来说，sql可能比XPath更容易使用。
sqlite的缺点：
>可能有问题与多个进程访问相同的数据库(可能不是你的情况)，
>你应该至少知道基本的sql。除非在缓存中有成千上万的项目，我不认为你会需要优化它，
>也许在某种程度上，从安全角度(sql注入)可能更危险。另一方面，你不是编码Web应用程序，所以这不应该发生。
其他的东西在两个解决方案可能。
总结一下，你的问题分别回答：
>你不会知道，除非你用两个后端测试你的具体应用程序。否则它总是只是一个猜测。对这两个缓存的基本支持不应该是代码的问题。然后进行基准和比较。>由于XML文件的组织方式，sqlite搜索应该总是更快(除去一些角落的情况下，它不重要，无论如何，因为它的速度快)。加速搜索XML将需要索引数据库，在你的情况下，这意味着缓存缓存，不是一个特别好的主意。但是使用sqlite，您可以将索引作为数据库的一部分。
