Является ли загрузка данных из SQLite быстрее, чем FILE IO на мобильных устройствах (смартфонах)? - PullRequest
0 голосов
/ 06 декабря 2011

Я создаю мобильное приложение на основе Phone Gap, чтобы сделать из него разные сборки для iPhone, Blackberry и Android.Это в основном браузерное приложение.

У меня есть большое количество файлов, которые будут отображаться пользователю в моем приложении (в основном, в виде электронных книг).Файлы будут отображаться пользователю в виде иерархии.Например,

Пользователь выбирает книгу (экран 1).Будут отображены все главы в книге (screen2).Затем пользователь выбирает главу, и все темы будут отображаться (Экран 3).Пользователь выбирает тему для чтения (экран 4).

У меня есть два подхода, и я не могу решить, какой из них будет лучше с точки зрения производительности и удовлетворения новых требований в будущем.

  1. Я буду хранить все данные в файле HTML (каждый файл для одной темы) и отображать их пользователю, читая файл из иерархических папок, отображая его в браузере как HTML.
  2. Сохранить всеHTML-данные в базу данных SQLite (каждая запись для одной темы) и извлечение данных из SQLite и отображение для пользователя.Поэтому каждый раз, когда мне нужно добраться до SQLite и получить данные для показа пользователю, поскольку вся моя книга доступна в БД.

также мое приложение не основано на собственной платформе.

Проблемы, с которыми я столкнусь в будущем, будут: Если я займусь файловым подходом, мои файлы будут статически лежать в папках, и в будущем, если я хочу объединить две темы, которые будут отображаться как один файл, мне потребуется выполнить файловую операцию, чтобы объединить его.Но если я использую базу данных, я могу выбрать те две записи, которые относятся к двум темам, и отобразить их в браузере.

Пожалуйста, порекомендуйте, что будет лучше

  1. С точки зрения производительности (быстрее, поскольку мобильные устройства имеют ограниченные ресурсы для интенсивной работы с БД)
  2. Гибкость для обработки данных.
  3. IS Доступ к SQLite с использованием Javascript (PhoneGap Framework) быстрее, чем вызовы на родном языке, и будет ли мой телефон реагировать на интенсивные операции с БД? Например: iOS.

Спасибо.

Ответы [ 2 ]

1 голос
/ 06 декабря 2011

Не зная всех деталей, невозможно сказать наверняка, но я думаю, что в будущем вы будете лучше подготовлены к масштабируемости, если пойдете по пути SQLite.С HTML-подходом, если он не работает, ваши возможности для улучшения очень ограничены.

0 голосов
/ 06 декабря 2011

Я думаю, что правильным способом было бы использовать БД.Однако на разных платформах есть некоторые моменты (например, выбор может зависеть от общего размера хранимых данных):

  1. Android.На Android и SQLite и файловые операции выполняются быстро.Все версии Android поддерживают SQLite.Я не слышал о проблемах ограничения размера БД.Однако по умолчанию БД хранится во внутренней памяти устройства.Я видел некоторые устройства, где внутренняя память устройства довольно короткая - всего около 50 МБ.Однако с дополнительными усилиями по внедрению можно разместить БД на SDCard.

  2. BB.BB это боль.На ББ файловые операции оказались намного медленнее, чем на Android.Я не пробовал SQLite на BB, хотя подозреваю, что он должен быть немного быстрее, поскольку он, вероятно, имеет некоторые низкоуровневые оптимизации, но не намного быстрее, поскольку SQLite основан на той же файловой системе.BB поддерживает SQLite начиная с BB OS 5.0.В BB OS 5.0 ограничение размера БД составляет 512 КБ, затем в BB OS 6.0 ограничение было увеличено до 5 МБ, и, наконец, в BB OS 7.0 ограничение было увеличено до 16 МБ.Обратите внимание, что существует также ограничение на запрос к БД.:) В BB OS 7.0 запрос может быть до 1 МБ.До BB OS 7.0 ограничение длины запроса составляло 4 КБ.Например, если вы собираетесь вставить большие фрагменты текста в БД, ограничение длины запроса в 4 КБ может быть болезненной проблемой.

  3. iPhone.Извините, к сожалению, я не знаю, что происходит на iPhone.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...