我'm trying to analyze the trade-offs between using SQLite vs. using resources for an app that needs to ship with a fairly sizeable amount of text (several books). I'已阅读this post on raw XML files vs. SQLite和this one on XML resources vs. SQLite . 但是，这两者似乎都在比较SQLite在运行时解析XML . 我不欣赏别人可以提供的任何见解 .
数据详情：约40本书;每本书三种语言;平均书长25章;平均章长25段;总计约75,000个段落 . 文本按段落存储;不需要更精细的粒度 . 对于每种语言，应用程序的文本逻辑视图都是跨越所有书籍的单个段落数组 . 还有段落级别的“目录”（TOC）数据 . 所有数据都是严格只读的 . 我需要支持两种查询类型：1）检索指定语言的段落或段落范围的文本; 2）给出一个段落编号，确定章节中的书籍，章节和段落偏移量 . 我不需要使用任何SQLite的字符串函数 .
我的分析到目前为止：
SQLite: 离线创建SQLite数据库，将其打包为原始资源或资产，并在应用程序首次运行（和/或升级）时将其复制到数据库位置 . 我已经为此实现了一个原型数据库，有六个表 .
-
可以使用SQL查询数据库，因此不需要编码任何搜索算法 .
-
我知道它可以处理这么多数据 .
-
需要多个SQL范围查询来回答类型2查询 .
-
需要两倍的空间：在.apk文件中，并在安装到应用程序的数据库区域时再次使用 .
-
Android 's SQLite implementation requires external storage (SD card), so app won'没有人工作 . 亚马逊的guidelines for Kindle Fire apps表示应用程序不能要求SD卡，因此以这种方式可能会排除Kindle Fire的兼容性 . （坏！）
Resources: 离线创建xml数组资源文件的集合并将它们复制到项目's res/values folder. Text would be partitioned into many string arrays: one array per chapter per book. There would be about 3,000 arrays. Indexes would be implemented as int arrays. For each book, the index data would be shared across languages. I'd可能还需要生成一些类型化的数组资源，以便为生成的资源ID提供索引 . 我希望索引数组足够小，可以在app启动时完全加载到内存中 .
-
类型1查询涉及加载正确的字符串数组和访问数组元素 . 类型2查询涉及（已加载的）索引数据的二进制搜索 .
-
不知道Android中的资源系统是否可以处理那么多资源数组 .
-
不知道与使用SQLite相比会有什么性能 .
我认为混合方法也是可能的：将TOC数据以一种方式存储，将文本本身存储在另一种方式中 .
同样，我会感谢任何有助于此分析的想法或见解 .
1 回答
一个切点......
今天的版本实际上是推荐的
对于较大的应用程序而不是完全打包它 . 此外，他们禁止的似乎是[强调我的]
所以这种限制现在已经过时了 .