Я пытаюсь проанализировать компромисс между использованием SQLite и использованием ресурсов для приложения, которое должно поставляться с довольно большим объемом текста (несколько книг). Я прочитал этот пост о сырых XML-файлах против SQLite и этот пост о XML-ресурсах против SQLite . Однако оба из них, похоже, сравнивают SQLite с анализом XML во время выполнения. Я не знаю, относятся ли те же проблемы к использованию строковых массивов и массивов ресурсов int. У меня действительно есть несколько неизвестных, и я буду благодарен за любые идеи, которые могут предложить другие.
Данные детали: около 40 книг; три языка на книгу; средняя длина книги 25 глав; средняя длина главы 25 абзацев; всего около 75 000 абзацев. Текст хранится по абзацу; не требуется более тонкой детализации. Для каждого языка логическое представление текста приложения представляет собой единый массив абзацев, охватывающий все книги. Существуют также данные «оглавления» (TOC) вплоть до уровня абзаца. Все данные только для чтения. Мне нужно поддерживать два типа запросов: 1) получить текст для абзаца или диапазона абзацев на указанном языке; 2) по номеру абзаца определите книгу, главу и смещение абзаца в главе. Мне не нужно использовать строковые функции SQLite.
Мой анализ пока:
SQLite: Создайте базу данных SQLite в автономном режиме, упакуйте ее в качестве необработанного ресурса или ресурса и скопируйте в расположение базы данных при первом запуске приложения (и / или повышен). У меня есть прототип базы данных для этого с полдюжины таблиц.
- Может использовать SQL для запроса базы данных, поэтому не нужно кодировать какие-либо алгоритмы поиска.
- Я знаю, что он может обрабатывать столько данных.
- Требуется несколько запросов диапазона SQL для ответа на запросы типа 2.
- Требуется вдвое больше места: в файле .apk и снова при установке в область базы данных приложения.
- Для реализации Android SQLite требуется внешнее хранилище (SD-карта), поэтому без него приложение не будет работать. В правилах Amazon для приложений Kindle Fire говорится, что приложениям не требуется SD-карта, поэтому такой способ может исключить совместимость Kindle Fire. (Плохо!)
Ресурсы: Создайте коллекцию файлов ресурсов массива XML в автономном режиме и скопируйте их в папку res / values проекта. Текст будет разбит на множество строковых массивов: один массив на главу на книгу. Там будет около 3000 массивов. Индексы будут реализованы как массивы int. Для каждой книги данные индекса будут распространяться по языкам. Возможно, мне также понадобится сгенерировать некоторые ресурсы типизированного массива, чтобы обеспечить индекс для сгенерированных идентификаторов ресурсов. Я ожидаю, что индексные массивы достаточно малы для полной загрузки в память при запуске приложения.
- Запросы типа 1 включают загрузку правильного массива (ов) и доступ к элементам массива. Запросы типа 2 включают двоичный поиск (уже загруженных) данных индекса.
- Не знаю, может ли система ресурсов в Android справиться с таким количеством массивов ресурсов.
- Не знаю, какую производительность можно сравнить с использованием SQLite.
Полагаю, возможен и гибридный подход: хранить данные оглавления одним способом, а сам текст - другим.
Опять же, я был бы признателен за любые мысли или идеи, которые помогут с этим анализом.