Resources vs. SQLite

I'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've read this post on raw XML files vs. SQLite and this one on XML resources vs. SQLite. Both of those, however, seem to be comparing SQLite to parsing XML at run time. I don't know if the same issues apply to using string and int resource arrays. I actually have a number of unknowns and I'd appreciate any insights others can offer.

Data details: about 40 books; three languages per book; average book length 25 chapters; average chapter length 25 paragraphs; about 75,000 paragraphs total. Text is stored by paragraph; no finer granularity needed. For each language, the app's logical view of the text is as a single array of paragraphs spanning all the books. There are also "table of contents" (TOC) data down to the paragraph level. All the data are strictly read-only. I need to support two query types: 1) retrieve the text for a paragraph or range of paragraphs in a specified language; 2) given a paragraph number, determine the book, chapter, and paragraph offset in the chapter. I don't need to use any of SQLite's string functions.

My analysis so far:

SQLite: Create an SQLite data base off-line, package it as a raw resource or asset, and copy it to the data base location when the app is run for the first time (and/or upgraded). I have a implemented a prototype data base for this with half a dozen tables.

1. Can use SQL to query data base, so don't need to code any search algorithms.
2. I know it can handle this much data.
3. Requires several SQL range queries to answer type 2 queries.
4. Requires twice the space: in the .apk file and again when installed into the app's db area.
5. Android's SQLite implementation requires external storage (SD card), so app won't work without one. Amazon's guidelines for Kindle Fire apps state that apps cannot require an SD card, so going this way might rule out Kindle Fire compatibility. (Bad!)

Resources: Create a collection of xml array resource files off-line and copy them to the project'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 probably also need to generate some typed array resources to provide an index into the generated resource IDs. I expect that the index arrays are small enough to load entirely into memory at app startup.

1. Type 1 queries involve loading the correct string array(s) and accessing array elements. Type 2 queries involve binary search of the (already loaded) index data.
2. Don't know whether the res开发者_运维知识库ources system in Android can handle that many resource arrays.
3. Don't know what the performance would be compared to using SQLite.

I suppose a hybrid approach is also possible: store the TOC data one way and the text itself in another.

Again, I'd appreciate any thoughts or insights that would help with this analysis.

One tangential point...

Amazon's guidelines for Kindle Fire apps state that apps cannot require an SD card, so going this way might rule out Kindle Fire compatibility. (Bad!)

The version from today actually recommends

that you deploy a smaller APK that downloads and installs quickly, and then upon first launch downloads additional resources and saves them on a local file system.

for larger apps instead of packaging it altogether. Additionally, what they forbid seems to be [emphasis mine]

copying, recording, downloading, storing, or similar actions of any type of video or audio content onto the Amazon Fire TV or Fire TV Stick device, any SD memory card or any connected external storage (where applicable).

So that restriction seems obsolete now.