資源與SQLite

Question

我想分析使用SQLite與使用資源的應用程序之間的權衡，需要運輸相當大量的文本（幾本書）。我讀過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數據的基礎上脫線，包它作爲原始資源或資產，並將其複製到數據的基礎位置，當應用程序被運行在第一次（和/或升級）。我有一個實現了這樣的原型數據庫與六個表。

1. 可以使用SQL查詢數據庫，所以不需要編寫任何搜索算法。
2. 我知道它可以處理這麼多的數據。
3. 需要幾個SQL範圍查詢來回答類型2查詢。
4. 需要兩倍的空間：在.apk文件中，並再次安裝到應用程序的數據庫區域。
5. Android的SQLite實現需要外部存儲（SD卡），所以沒有一個應用程序將無法正常工作。亞馬遜的guidelines for Kindle Fire apps表示，應用程序不需要SD卡，所以這樣做可能會排除Kindle Fire的兼容性。 （壞！）

資源：創建的XML陣列的資源文件的集合脫線，並將它們複製到項目的res /文件夾值。文本將被分割成許多字符串數組：每本書每章一個數組。將會有大約3000個陣列。索引將以int數組的形式實現。對於每本書，索引數據將在各種語言之間共享。我可能還需要生成一些類型化的數組資源來爲生成的資源ID提供索引。我期望索引數組足夠小，可以在應用程序啓動時完全加載到內存中。

1. 類型1查詢涉及加載正確的字符串數組和訪問數組元素。類型2查詢涉及（已經加載的）索引數據的二進制搜索。
2. 不知道Android中的資源系統是否可以處理那麼多的資源數組。
3. 不知道與使用SQLite相比，性能會如何。

我想一個混合的方法也是可能的：存儲TOC數據的一種方式和文本本身在另一種。

再次，我會很感激任何想法或見解，這將有助於此分析。

Answer 1

一個切點......

亞馬遜對Kindle Fire的準則應用包含的應用程序不能要求一個SD卡，所以會這樣，可能會排除Kindle Fire的兼容性狀態。 （壞！）

從今天的版本實際上建議

您部署一個較小的APK是下載和安裝快捷，然後在第一次啓動下載額外的資源並將它們保存在本地文件系統上。

更大的應用程序，而不是完全打包。此外，他們還禁止似乎是[重點煤礦]

複製，記錄，下載，儲存，或任何類型的視頻或音頻內容的類似行動到亞馬遜消防電視或防火電視棒設備，任何SD存儲卡或任何連接的外部存儲（如果適用）。

因此，限制似乎已經過時了。