Плюсы и минусы SQLite и общих настроек [закрыто]

156

Каков хороший механизм для хранения информации между базой данных SQLite и общими настройками?

Зачем использовать общие настройки? Зачем использовать sqlite? Я пытался найти разницу между ними, и какой механизм хранения данных лучше, но я не могу найти подходящий ответ в Google. Пожалуйста, помогите мне с примером и объяснениями.

Rana.S
источник
Это в значительной степени зависит от вида данных, которые вы хотите сохранить. SharedPreferences обеспечивает более быстрый и простой доступ к данным, его удобнее использовать при хранении небольших объемов данных.
Егор
2
Не храните ничего в Shared Preferences, кроме простых строк и примитивов - и если вы используете отдельный файл для каждого - несмотря на то, что документы Shared Preferences не являются поточно-ориентированными, и даже если они используются исключительно в основном потоке, чрезвычайно подвержены повреждению, если вы храните больше чем 1 пара ключ-значение в файле.
RunLoop
SharedPreferences кэшируются в памяти после первого использования, поэтому они должны быть довольно быстрыми при последующих операциях чтения.
Стэн

Ответы:

169

Это действительно зависит от данных, которые вы хотите сохранить.

SQLite

Большие объемы таких же структурированных данных должны храниться в базе данных SQLite, поскольку базы данных предназначены для данных такого типа. Поскольку данные структурированы и управляются базой данных, их можно запросить, чтобы получить подмножество данных, которое соответствует определенным критериям, используя язык запросов, такой как SQL. Это позволяет искать в данных. Конечно, управление и поиск больших наборов данных влияет на производительность, поэтому чтение данных из базы данных может быть медленнее, чем чтение данных из SharedPreferences.

SharedPreferences

SharedPreferences - это хранилище ключей / значений, в котором вы можете сохранить данные под определенным ключом. Чтобы прочитать данные из магазина, вы должны знать ключ данных. Это делает чтение данных очень простым. Но хранить небольшой объем данных так же просто, как и сложно хранить и считывать большие структурированные данные, так как вам необходимо определить ключ для каждой отдельной информации, кроме того, вы не можете реально искать в данных, если у вас нет определенной концепции для называя ключи.

Фло
источник
24
В качестве примера, SharedPreferences полезны для хранения пользовательских настроек, где есть лишь несколько переменных, которые необходимо сохранить. SQLite, с другой стороны, был бы лучше для хранения данных там, где имеется большой набор элементов, таких как названия песен в музыкальной библиотеке, которые необходимо найти.
CL22
5
Вам не нужно знать имена ключей, чтобы использовать SharedPreferences. Смотрите getAll ().
ЗаБланк
5
К вашему сведению, существует ТРЕТЬЯ опция: чтение / запись XML в файл. (См. Классы android.util.xml). Подходит для умеренно сложных данных, которые могут быть прочитаны / записаны одновременно. Например, сетка значений, которую пользователь меняет не часто. Особенно если это данные, которые вы, возможно, позже захотите отправить в другое место, поэтому вам понадобится разобрать их в формате.
ToolmakerSteve
1
Желательно ли сохранить JSON в виде строки JSON в общий преф?
Kaveesh Kanwal
2
@JCarlos Пока вы не занимаетесь кросс-процессами, вы будете в порядке, используя SharedPreferences.
Mygod
97

На этот вопрос есть принятый ответ, но я думаю, что есть еще что сказать по теме - относительно скорости.

SharedPreferences и Sqlite DB приложения - это просто файлы, хранящиеся в каталогах приложения в файловой системе устройства. Если объем данных не слишком велик, опция Sqlite будет включать в себя более крупный и сложный файл с дополнительными издержками обработки для простого доступа.

Таким образом, если характер данных не диктует ваш выбор (как объяснено в принятом ответе) и скорость имеет значение, то вам, вероятно, лучше использовать SharedPreferences.

И чтение некоторых данных часто находится на критическом пути к отображению основной активности, поэтому я думаю, что скорость часто очень важна.

Последнее соображение относительно скорости и эффективности - если вам нужно использовать базу данных Sqlite для некоторых структурированных данных, то, вероятно, более эффективно также сохранять пользовательские настройки в базе данных, чтобы не открывать второй файл. Это довольно незначительное соображение, которое, вероятно, стоит рассмотреть, только если вам необходимо получить доступ как к структурированным данным, так и к предпочтениям, прежде чем вы сможете отобразить основное действие.

Том
источник
6
Как насчет читаемости кода? Я думаю, что при хранении нескольких записей в SharedPrefs вместо таблицы БД код становится запутанным. Синтаксис Sql легче читать, чем циклически проходить по записям SharedPrefs ...
Игорь Ганапольский
8
Игорь, я бы не согласился. SharedPreferences действительно одномерны, очень просто использовать предпочтения. Например, я создаю приложение для проверки акций, я просто храню символы акций в настройках. Мне не нужно брать их по отдельности, так как я всегда перечисляю их все, и это все, что я делаю, храни или храню. Это так просто, намного проще, чем использовать БД.
AutoM8R
1
Я не могу вспомнить ситуацию, когда читаемость кода затрудняется, а структура сохраняемых данных не требует использования иерархической базы данных. Даже если есть какие-либо проблемы с читабельностью, это можно решить с помощью класса-оболочки с необходимыми функциями.
Сарат Садасиван Пиллай
1
Можем ли мы сохранить несколько значений ключей в виде данных jsonstring в общих настройках? Есть ли ограничение по количеству символов, которое может обрезать мои значения json?
Нова
2
SharedPreferences загружаются в память только один раз (за жизненный цикл процесса приложения) и хранятся там; после этого это всегда супер быстро. Таким образом, на самом деле не существует практического выигрыша в производительности, если данные SharedPref помещать в SQLite (просто ради того, чтобы избежать дополнительного доступа к файлу SharedPref). И, кстати, вы не должны помещать свои вещи SQLite в SharedPrefs; как я уже сказал, это всегда в памяти, что может вызвать проблемы (нехватки памяти).
Жолт Сафрани
20

Я считаю, что речь идет не о скорости или размере, а о типах операций, которые вы хотите выполнить с вашими данными.

Если вы планируете сделать присоединиться , своего рода , и другие операции БД на данных затем пойти на Sqlite . Примером является сортировка данных по дате.

Если вы хотите отобразить простые значения (например, int, boolean, String), используйте Preferences . Операции с БД здесь не будут работать и, разумеется, вам нужны все ключи. Примером является пароль пользователя или конфигурация приложения.

Большой соблазн для использования Preferences - это когда вы хотите использовать его для хранения сплющенного POJO (сериализованного объекта JSON) в виде String. Наличие такой необходимости на самом деле является признаком использования Sqlite. Зачем ? Потому что сложные данные в конечном итоге потребуют сложных операций. Представьте себе получение определенной записи, которая может быть обработана простым «SELECT ... WHERE id = 1». В пути Preferences это будет долгий процесс от десериализации до итерации результатов.

inmyth
источник
Кроме того, SharedPreferences не поддерживает транзакции, поэтому, если вам нужны транзакции, используйте SQLite. Например, если пользователь нажимает кнопку «Выход», вы можете удалить несколько SharedPreferencesключевых / значений одновременно (например , как userи passwordклавиши), так что вы будете уверены , что либо обе кнопки убираются или оба установлены.
Runeks
5
  • Для хранения огромного количества данных используйте систему баз данных SQLite. Это позволит пользователю также искать данные.

  • С другой стороны, для хранения небольшого объема данных перейдите к разделу «Общие настройки». В этом случае огромная система баз данных не нужна. Это позволит пользователю просто сохранять данные и загружать их.

Сами Аль-Джабар
источник
1
300 пар ключ-значение - это огромный объем данных? Мне нужно хранить это точно.
JCarlosR
1
В этом случае вам следует перейти на базу данных SQLite. В противном случае будет сложно управлять этими 300 данными и получать их.
Сами Аль-Джабар
Но если все ключи известны, не будет ли проще получить данные из общих настроек?
Арджун
-6

Забудьте SQLLite, забудьте SharedPreferences, используйте Realm. Единое решение для всего вашего локального хранилища. Вы можете использовать простые старые объекты Java в качестве объектов RealmObject и хранить там свои данные. Вы можете конвертировать выбранные запросы в файлы JSON. Не нужно разбирать всю базу данных. Проверьте эту ссылку: https://realm.io/news/introduction-realm/

greenspand
источник
12
забудьте все, что вы знаете о чехлах.
Андрей Г