我希望能够将媒体 RSS和iTunes 播客RSS 提要存储到数据库中。这里的要求是我不想错过提要中的任何元素或其属性。在提要中找到所有最常见的元素并将它们作为单独的列存储在数据库中是有意义的。这里的问题是可能存在可能不是标准的特定饲料元素。我也想抓住他们。由于我不知道它们可以是什么，所以我不会为它们设置专门的专栏。
目前我有 2 个表，称为 feeds 和 feed_entries。对于像附件、类别这样的 RSS 2.0 标签，我有单独的表，它们与提要/提要条目有关联。我正在使用 feedzirra 来解析提要。Feedzirra 要求我们知道要解析的提要中的元素，因此我们不知道提要是否包含超出 feedzirra 可以理解的元素。
将这些提要存储在数据库中并且不会错过任何信息的最佳方法是什么？（将整个提要转储到数据库中是行不通的，因为我们想查询大部分属性）。什么解析器最适合？选择 Feedzirra 是为了提高性能，但是，将提要中的所有数据都放入数据库是一个优先事项。
更新
我使用 MySQL 作为数据库。
我还根据提要和条目对数据库进行了建模，并交叉映射了 RSS、RDF 和 Atom 的字段，因此我可以捕获所需的数据字段作为起点。然后我添加了一些其他的标记和我自己的提要内部摘要，以及一些内务和维护字段。
如果您从 Feedzirra 迁移，我建议您将实际的提要 XML 临时存储在临时表中，以便您可以使用Nokogiri对其进行后期处理对其进行后期处理。这样一来，您的 HTTP 进程就不会陷入处理文本的困境，它只是检索内容并将其归档，并更新处理时间的记录，以便您知道何时再次检查。后处理可以从存储的 XML 中提取您想要的提要信息以存储在数据库中，然后删除记录。这意味着有一个进程会尽可能快地定期拉入提要，而另一个基本上在后台运行的进程正在快速运行。
此外，Typhoeus/Hydra和HTTPClient都可以很好地处理多个 HTTP 请求并且易于设置。
将 XML 存储为 CLOB，大多数数据库都有 XML 处理扩展，允许您将 XPath 类型查询作为 SELECT 语句的一部分。
否则，如果您的 DBMS 不支持 XML 查询，请使用您的语言 XPath 实现来查询 CLOB。您可能需要将某些元素提取到表列中以便快速查询。