资源与SQLite

Question

我正在尝试分析使用SQLite与使用资源之间的权衡，这些应用需要附带相当大量的文本（几本书）。我看过this post on raw XML files vs. SQLite和this one on XML resources vs. SQLite。但是，这两者似乎都在比较SQLite在运行时解析XML。我不知道相同的问题是否适用于使用字符串和int资源数组。我实际上有许多未知数，我很欣赏其他人可以提供的任何见解。

数据详情：约40本书;每本书三种语言;平均书长25章;平均章长25段;总计约75,000个段落。文本按段落存储;不需要更精细的粒度。对于每种语言，应用程序的文本逻辑视图都是跨越所有书籍的单个段落数组。还有段落级别的“目录”（TOC）数据。所有数据都是严格只读的。我需要支持两种查询类型：1）检索指定语言的段落或段落范围的文本; 2）给出一个段落编号，确定章节中的书籍，章节和段落偏移量。我不需要使用任何SQLite的字符串函数。

到目前为止我的分析：

SQLite：离线创建SQLite数据库，将其打包为原始资源或资产，并在首次运行应用程序时将其复制到数据库位置（和/或升级）。我已经为此实现了一个原型数据库，有六个表。

1. 可以使用SQL查询数据库，因此不需要编码任何搜索算法。
2. 我知道它可以处理这么多数据。
3. 需要多个SQL范围查询才能回答第2类查询。
4. 需要两倍的空间：在.apk文件中，再次安装到应用程序的数据库区域时。
5. Android的SQLite实现需要外部存储（SD卡），因此没有一个应用程序将无法运行。亚马逊的guidelines for Kindle Fire apps表示应用程序不需要SD卡，因此这样做可能会排除Kindle Fire的兼容性。 （错误！）

资源：离线创建xml数组资源文件的集合，并将它们复制到项目的res / values文件夹中。文本将被分区为许多字符串数组：每本书每章一个数组。将有大约3,000个阵列。索引将实现为int数组。对于每本书，索引数据将跨语言共享。我可能还需要生成一些类型化的数组资源，以便为生成的资源ID提供索引。我希望索引数组足够小，可以在app启动时完全加载到内存中。

1. 类型1查询涉及加载正确的字符串数组和访问数组元素。类型2查询涉及（已加载的）索引数据的二进制搜索。
2. 不知道Android中的资源系统是否可以处理那么多资源数组。
3. 不知道与使用SQLite相比会有什么表现。

我认为混合方法也是可行的：将TOC数据单向存储，将文本本身存储在另一种方式中。

同样，我会感谢任何有助于此分析的想法或见解。

Answer 1

一个切向点......

  

亚马逊针对Kindle Fire应用程序的指南指出，应用程序不需要SD卡，因此以这种方式可能会排除Kindle Fire的兼容性。 （错误！）

今天的版本实际推荐

  

您部署较小的APK，可以快速下载和安装，然后在首次启动时下载其他资源并将其保存在本地文件系统中。

适用于较大的应用，而不是完全打包。此外，他们禁止的似乎是[强调我的]

  

将任何类型的视频或音频内容的复制，录制，下载，存储或类似操作复制到Amazon Fire TV或Fire TV Stick设备，任何SD存储卡或任何连接的外部存储设备（如果适用）。

所以这种限制现在已经过时了。