所以我正在编写一个非常重视SQLite用法的应用程序。我正在编写我的应用程序内存缓存系统，这将允许我对我的数据进行排序和过滤（本质上是我自己的个人核心数据）。我这样做是因为在我看来，这是一个比从SQLite数据库不断发出读取请求更好/更快的选择。此外，大多数字段/列将是可搜索/可排序的，并且在每个字段/列上设置索引似乎不太理想。但我不确定。我知道SQLite数据库缓存在内存中，但我不知道对我来说有多大程度或多少优势。实现我自己的缓存系统将是复杂的，可能会增加我的内存占用，特别是因为我将每个表完全加载到内存中以执行排序/过滤器。如果它有助于我的应用程序的性能，我非常愿意这样做，但它会吗？ SQLite缓存是否足以让我完全依赖于它，或者当表开始变大（超过10,000行）时它会陷入困境吗？我想我在问是否有人有足够的经验与SQLite推荐一个在另一个。
在有人问之前：不，我不能使用核心数据。核心数据不够灵活，我无法在我的应用程序中使用。
答案 0 :(得分：1)
好的，所以这就是我的想法：选择在很大程度上取决于您的要求。我最终删除（尽可能多）SQLite缓存，加载我需要的东西，并使用我自己的例程对它进行排序/过滤。这对我来说效果非常好。但我通过实现这一点意识到这在很多情况下都不会起作用。具体来说，我已经做了很多工作来确保我的数据库大小尽可能小。我基本上只存储简单/小文本和数字。其他所有内容都是对外部文件的引用。这使得我的数据库足够小，可以使用less作为数据库，而更多地作为索引服务，这适用于将信息加载到内存和排序/过滤。
所以，答案很大程度上取决于数据库。如果您要存储可能占用大量内存的大字段，那么最好让SQLite处理缓存。另一方面，如果您知道字段会很小，那么SQLite缓存只会使您的内存膨胀，而往返数据库的往返分类/过滤数据只会增加您的延迟。相反，最好自己进行排序/过滤，不过我承认这很有用。但最终它使我的应用程序比将其转发到数据库要快得多。