我正在创建一个RSS阅读器作为一个爱好项目，并且在用户添加自己的URL的时候。

我在想两件事。

• 一个纯文本文件，其中每个url为一行
• 可以在URL后面有唯一ID和描述的SQLite

是SQLite的想法会产生很大的开销，还是有更好的方法来执行此类操作？

解决方案

为什么不使用XML？

如果我们仍在处理RSS，则可能会：:)

作为OPML文件呢？它是XML，因此如果我们需要存储更多数据，而OPML规范提供了该数据，则始终可以添加自己的名称空间。

另外，从其他RSS阅读器导入和导出都是通过OPML完成的。通常，它会提供库支持。如果我们有兴趣让用户切换，则必须支持OPML。坦斯克(Thansk)向贾梅什(Jamesh)提出了这一点。

我们是否打算仅存储URL？还是我们打算添加诸如last_fetch_time之类的数据？

如果程序只是一个简单的URL列表，它将逐行读取并下载数据，则将其存储在文件中，甚至更好地存储在写入文件的某些序列化对象中。

如果我们打算扩展它，添加注释/最后一次获取的时间，等等，那么我会选择SQLite，它没有那么多开销。

如果它是仅具有一个实例的单个用户应用程序，则SQLite可能会过大。

正如我所见，我们有几种选择：

• SQLite /数据库层。增加了代码运行所需的依赖关系。但允许并发访问
• 滚动自己的文本解析器。当我们要保存更多数据并重新发明轮子时，复杂性会增加。较少的依赖关系，并且最初虽然数据很简单，但是对于应用程序的新手来说，编辑它是微不足道的。
• 使用XML。格式正确，定义明确且可文本编辑。虽然仅存储一个URL可能会过大。
• 使用诸如pickle之类的东西来序列化对象并将其保存到磁盘。更改数据结构意味着"升级"泡菜文件。对于新手来说，编辑起来不是很直观，但是非常容易实现。

我会选择XML文本文件选项。我们可以使用Visual Studio内置的XSD工具从XML数据创建DataTable，并在需要时轻松地将其序列化回文件中。

另一个警告是，我确定我们希望最终用户能够对他们的RSS feed进行分类，并能够对其进行搜索/排序，而拥有这种数据表样式将对此有所帮助。

我们将获得轻松的文件存储和访问，这是"数据库"结构的好处，但SQLite的开销却不大。