Как стать автором
Обновить

Комментарии 17

Не используйте SQLite просто потому, что это «модно». Продумайте альтернативы: XML, например. За использование SQLite нужно платить тратой ресурсов.
Хорошо, тогда вопрос: а когда следует использовать SQLite?

Я во многих проектах использую базу:
1) В играх храню информацию о всех покупках внутриигровых.
2) В бизнес-приложениях храню кэши данных, чтобы с сети не тягать постоянно.
Лучше так не делать? В xml под Android я вообще почти ничего храню, к примеру; только небольшие данные через SharedPreferences.
Следует или нет вопрос тонкий, но выше обозначенное вполне можно реализовать и на файлах.
1) Использую зашифрованный JSON в файле,
2) Завёл отдельную директорию, в которой кэширую в основном картинки. Имена файлов — хэш от URL.
Этот совет предостерегает от использования SQLite «на все случаи жизни». Ваши сценарии как раз подходят хорошо.

Контрпример: какой-то небольшой справочник. Его проще положить и использовать в виде XML.
А чем проще-то?
Ну, например, справочник уже есть и он в XML формате. Стоит вопрос — переводить это все в SQLite или оставить как есть? На платформе Андроид получить данные из XML файла довольно просто.

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

Если разделить индексный файл и блоб-файл, то в SQLite можно хранить все что угодно, так же как и в файловой системе, практически без оверхеда.
Что значит «разделить индексный файл и блоб-файл»? Две базы SQLite в двух разных файлах, и в одной из них блобы только?
Да. В одной делаем выборки, поиск и что угодно, а другой запрашиваем данные уже по конкретным ID, без поиска. У меня так гигабайтная база крутится с картинками. Вполне шустро.
В принципе, лучше перед советами почитать документацию сайте SQLite, там все доступно описано, полезные вещи для себя можно приметить.
А потом обязательно почитать, какой используется SQLite на вашей платформе, какие есть дополнительные функции, что поддерживает, а что отключено. Если что, всегда можно посмотреть план запроса.

a) не все читают английский;
b) документации очень много;
c) некоторые соображения трудно найти даже в документации, нужно много «шерстить»;
Я пишу с той точки зрения, что неплохо представлять, что и как работает, перед использованием в своем коде. Необязательно сразу же копать на всю глубину.
Позвольте дополнить ваш пост ссылками:
Вот, то чего не хватает статье! Спасибо за подборку.
И вообще чуть ли не каждый подзаголовок статьи можно закончить ", Ваш КО" ибо какие-то прописные истины, кроме м.б. раздела "Дополнено". Про разработку собственно ни слова…
Как быстро добавить много записей (bulk insert)?

Обернуть кучу инсертов в транзакцию.
А никто не подскажет, как правильно организовать работу с серверной базой? То есть я предполагаю, что на устройстве должна быть практически полная копия базы на сервере (чтобы не гонять туда-сюда информацию постоянно). С другой стороны возникает куча всяких проблем с синхронизацией тогда. Вроде как проще постоянно держать всё только на сервере и брать только когда надо и что надо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории