Xml 或 Sqlite，何时为数据库删除 Xml? [英] Xml or Sqlite, When to drop Xml for a Database?
问题描述
我真的很喜欢用 Xml 来保存数据，但是什么时候 sqlite/database 成为更好的选择?例如，当 xml 有超过 x 个项目或大于 y MB 时?
I really like Xml for saving data, but when does sqlite/database become the better option? eg, when the xml has more than x items or is greater than y MB?
我正在编写一个 rss 阅读器，我相信我在使用 xml 而非 sqlite 数据库来存储所有提要项目的缓存时做出了错误的选择.有一些提要在一个月后的 xml 文件大约为 1mb，另一个有超过 700 个项目，而大多数只有大约 30 个项目，并且在 几个月后 大小大约为 50kb.
I am coding an rss reader and I believe I made the wrong choice in using xml over a sqlite database to store a cache of all the feeds items. There are some feeds which have an xml file of ~1mb after a month, another has over 700 items, while most only have ~30 items and are ~50kb in size after a several months.
我目前没有实施上限的计划，因为我喜欢能够搜索所有内容.
I currently have no plans to implement a cap because I like to be able to search through everything.
所以，我的问题是:
- sqlite/数据库的开销何时比使用 xml 更合理?
- 当有很多小的 xml 文件时，几个大的 xml 文件对于数据库来说是否足够合理，尽管即使是小的文件也会随着时间的推移而增长?(很长时间很长时间)
- When is the overhead of sqlite/databases justified over using xml?
- Are the few large xml files justification enough for the database when there are a lot of small ones, though even the small ones will grow over time? (a long long time)
更新(更多信息)
每次在 GUI 中选择提要时，我都会重新加载该提要 xml 文件中的所有项目.
Every time a feed is selected in the GUI I reload all the items from that feeds xml file.
我还需要修改已读/未读状态，当我遍历 xml 中的所有节点以查找该项目然后将其设置为已读/未读时，这似乎非常棘手.
I also need to modify the read/unread status which seems really hacky when I loop through all nodes in the xml to find the item and then set it to read/unread.
推荐答案
我基本同意 Mitchel，这可能是非常具体的，具体取决于您要使用 XML/sqlite 做什么.对于您的情况(缓存)，在我看来，使用 sqlite(或其他嵌入式数据库)更有意义.
I basically agree with Mitchel, that this can be highly specific depending on what are you gonna do with XML/sqlite. For your case (cache), it seems to me that using sqlite (or other embedded dbs) makes more sense.
首先，我真的不认为 sqlite 会比 XML 需要更多的开销.我的意思是开发时间开销和运行时开销.唯一的问题是您依赖于 sqlite 库.但是因为无论如何你都需要一些 XML 库所以没关系(我假设项目是在 C/C++ 中).
First I don't really think that sqlite will need more overhead than XML. And I mean both development time overhead and runtime overhead. Only problem is that you have a dependance on sqlite library. But since you would need some library for XML anyway it doesn't matter (I assume project is in C/C++).
sqlite 相对于 xml 的优势:
- 所有内容都在一个文件中，
- 随着缓存变大，性能损失低于 XML，
- 您可以将提要元数据与缓存本身(其他表)分开，但可以以相同的方式访问，
- 对于大多数人来说，SQL 可能比 XPath 更容易使用.
sqlite的缺点:
- 多个进程访问同一个数据库可能会出现问题(可能不是你的情况)，
- 您应该至少了解基本的 SQL.除非缓存中有数十万个项目，否则我认为您不需要对其进行太多优化，
- 从安全角度(SQL 注入)来看，它可能在某种程度上更危险.另一方面，您不是在编写网络应用程序，因此不应该发生这种情况.
这两种解决方案的其他方面可能相当.
Other things are on par for both solutions probably.
总结一下，分别回答你的问题:
To sum it up, answers to your questions respectively:
您不会知道，除非您使用两个后端测试您的特定应用程序.否则它总是只是一个猜测.对两种缓存的基本支持对代码来说应该不是问题.然后进行基准测试和比较.
You will not know, unless you test your specific application with both backends. Otherwise it's always just a guess. Basic support for both caches should not be a problem to code. Then benchmark and compare.
由于 XML 文件的组织方式，sqlite 搜索应该总是更快(除非在某些极端情况下它无关紧要，因为它非常快).无论如何，加速 XML 中的搜索都需要索引数据库，在您的情况下，这意味着缓存缓存，这不是一个特别好的主意.但是使用 sqlite，您可以将索引作为数据库的一部分.
Because of the way XML files are organized, sqlite searches should always be faster (barring some corner cases where it doesn't matter anyway because it's blazingly fast). Speeding up searches in XML would require index database anyway, in your case that would mean having cache for cache, not a particularly good idea. But with sqlite you can have indexing as part of database.
这篇关于Xml 或 Sqlite，何时为数据库删除 Xml?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
