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

Question

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

115

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

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

Rana.S 08 июнь 2011, в 09:15

Источник

0

Это в значительной степени зависит от вида данных, которые вы хотите сохранить. SharedPreferences обеспечивает более быстрый и простой доступ к данным, его удобнее использовать при хранении небольших объемов данных.
Egor 08 июнь 2011, в 09:04
2

Не храните ничего в Shared Preferences, кроме простых строк и примитивов - и если вы используете отдельный файл для каждого - несмотря на то, что документы Shared Preferences не являются поточно-ориентированными, и даже если они используются исключительно в основном потоке, чрезвычайно подвержены повреждению, если вы сохраните больше чем 1 пара ключ-значение в файле.
RunLoop 08 дек. 2013, в 06:17
0

SharedPreferences кэшируются в памяти после первого использования, поэтому они должны быть довольно быстрыми при последующих операциях чтения.
Stan 29 май 2017, в 08:27

Показать ещё 1 комментарий

Теги:

database

sqlite

android

sharedpreferences

data-storage

5 ответов

70

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

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

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

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

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

Tom 27 нояб. 2012, в 04:04

5

Как насчет читаемости кода? Я думаю, что при хранении нескольких записей в SharedPrefs вместо таблицы БД код становится запутанным. Синтаксис Sql легче читать, чем зацикливание записей SharedPrefs ...
IgorGanapolsky 10 июль 2013, в 03:55
6

Игорь, я бы не согласился. SharedPreferences действительно одномерны, очень просто использовать предпочтения. Например, я создаю приложение для проверки акций, я просто храню символы акций в настройках. Мне не нужно брать их по отдельности, так как я всегда перечисляю их все, и это все, что я делаю, храни или храню. Это так просто, намного проще, чем использовать БД.
AutoM8R 07 дек. 2013, в 18:02
1

Я не могу вспомнить ситуацию, когда читаемость кода затрудняется, а структура сохраняемых данных не требует использования иерархической базы данных. Даже если есть какие-либо проблемы с читабельностью, их можно решить с помощью класса-оболочки с необходимыми функциями.
Sarath Sadasivan Pillai 23 июнь 2014, в 07:21
1

Можем ли мы сохранить несколько значений ключей в виде данных jsonstring в общих настройках? Есть ли ограничение по количеству символов, которое может обрезать мои значения json?
Nova 22 сен. 2014, в 06:47
1

SharedPreferences загружаются в память только один раз (за жизненный цикл процесса приложения) и хранятся там; после этого это всегда супер быстро. Таким образом, на самом деле не существует практического выигрыша в производительности, если поместить данные SharedPref в SQLite (просто ради того, чтобы избежать дополнительного доступа к файлу SharedPref). И, кстати, вы не должны помещать свои вещи SQLite в SharedPrefs; как я уже сказал, это всегда в памяти, что может вызвать проблемы (нехватки памяти).
Zsolt Safrany 15 янв. 2015, в 17:23
0

Использует ли sqlite больше оперативной памяти, чем общее предпочтение, если мы вставляем / обновляем каждые 2-3 секунды?
SkyTreasure 18 янв. 2015, в 14:38
0

Мои (очень упрощенные) аналогии для обоих: SharedPreferences - это карта, SQLite - это список. Оба имеют разные варианты использования.
Populus 29 янв. 2015, в 15:01
0

Что будет правильным определением «большой» в «природе данных, не слишком больших»?
user1841702 11 фев. 2016, в 01:09

Показать ещё 6 комментариев

10

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

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

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

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

inmyth 06 апр. 2015, в 04:43

1

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

Sami Al-Jabar 06 нояб. 2015, в 08:00

0

300 пар ключ-значение - это огромный объем данных? Мне нужно хранить это точно.
JCarlos 31 янв. 2017, в 12:57
0

В этом случае вы должны перейти на базу данных SQLite. В противном случае будет сложно управлять этими 300 данными и получать их.
Sami Al-Jabar 11 май 2017, в 09:45

-2

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

greenspand 27 нояб. 2015, в 12:08

9

забудьте все, что вы знаете о чехлах.
Andrew G 08 апр. 2016, в 20:19

Ещё вопросы

Это в значительной степени зависит от вида данных, которые вы хотите сохранить. SharedPreferences обеспечивает более быстрый и простой доступ к данным, его удобнее использовать при хранении небольших объемов данных.
Не храните ничего в Shared Preferences, кроме простых строк и примитивов - и если вы используете отдельный файл для каждого - несмотря на то, что документы Shared Preferences не являются поточно-ориентированными, и даже если они используются исключительно в основном потоке, чрезвычайно подвержены повреждению, если вы сохраните больше чем 1 пара ключ-значение в файле.
SharedPreferences кэшируются в памяти после первого использования, поэтому они должны быть довольно быстрыми при последующих операциях чтения.
Как насчет читаемости кода? Я думаю, что при хранении нескольких записей в SharedPrefs вместо таблицы БД код становится запутанным. Синтаксис Sql легче читать, чем зацикливание записей SharedPrefs ...
Игорь, я бы не согласился. SharedPreferences действительно одномерны, очень просто использовать предпочтения. Например, я создаю приложение для проверки акций, я просто храню символы акций в настройках. Мне не нужно брать их по отдельности, так как я всегда перечисляю их все, и это все, что я делаю, храни или храню. Это так просто, намного проще, чем использовать БД.
Я не могу вспомнить ситуацию, когда читаемость кода затрудняется, а структура сохраняемых данных не требует использования иерархической базы данных. Даже если есть какие-либо проблемы с читабельностью, их можно решить с помощью класса-оболочки с необходимыми функциями.
Можем ли мы сохранить несколько значений ключей в виде данных jsonstring в общих настройках? Есть ли ограничение по количеству символов, которое может обрезать мои значения json?
SharedPreferences загружаются в память только один раз (за жизненный цикл процесса приложения) и хранятся там; после этого это всегда супер быстро. Таким образом, на самом деле не существует практического выигрыша в производительности, если поместить данные SharedPref в SQLite (просто ради того, чтобы избежать дополнительного доступа к файлу SharedPref). И, кстати, вы не должны помещать свои вещи SQLite в SharedPrefs; как я уже сказал, это всегда в памяти, что может вызвать проблемы (нехватки памяти).
Использует ли sqlite больше оперативной памяти, чем общее предпочтение, если мы вставляем / обновляем каждые 2-3 секунды?
Мои (очень упрощенные) аналогии для обоих: SharedPreferences - это карта, SQLite - это список. Оба имеют разные варианты использования.
Что будет правильным определением «большой» в «природе данных, не слишком больших»?
300 пар ключ-значение - это огромный объем данных? Мне нужно хранить это точно.
В этом случае вы должны перейти на базу данных SQLite. В противном случае будет сложно управлять этими 300 данными и получать их.
забудьте все, что вы знаете о чехлах.

Flo · Accepted Answer · 2011-06-08T10-42-00.000Z

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

SQLite

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

SharedPreferences

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

В качестве примера, SharedPreferences полезны для хранения пользовательских настроек, где есть лишь несколько переменных, которые необходимо сохранить. SQLite, с другой стороны, был бы лучше для хранения данных там, где имеется большой набор элементов, таких как названия песен в музыкальной библиотеке, которые необходимо найти.
Вам не нужно знать имена ключей, чтобы использовать SharedPreferences. Смотрите getAll ().
К вашему сведению, существует ТРЕТЬЯ опция: чтение / запись XML в файл. (См. Классы android.util.xml). Подходит для умеренно сложных данных, которые могут быть прочитаны / записаны одновременно. Например, сетка значений, которую пользователь меняет не часто. Особенно, если это данные, которые вы, возможно, позже захотите отправить в другое место, поэтому они потребуются в разбираемом формате.
Но SharedPreferences хранит пары ключ-значение в файле XML. Только то, что вам не нужно писать свой собственный xml-анализатор и самостоятельно управлять протоколом сохранения.
Желательно ли сохранить JSON в виде строки JSON в общий преф?
Обратите внимание, что SharedPreferences не безопасен для процессов.
@Mygod Это означает, что не может загружаться sharedPreferences, но операции SQLite всегда будут выполняться? Я должен хранить 300 значений (фиксированный объем данных), это хорошая идея использовать sharedPreferences?
@JCarlos Пока вы не занимаетесь кросс-процессами, все будет в порядке с SharedPreferences.
@Flo, у меня есть Json Response, вы можете увидеть этот JSON Response по этой ссылке -> samples.openweathermap.org/data/2.5/… . Это в основном дает мне прогноз погоды на 5 дней. мне нужно обновлять этот прогноз каждый день и хранить его где-нибудь, чтобы использовать в своем пользовательском интерфейсе. Я запутался между кэшированием этого ответа в SharedPreferences или SQLITE. Пожалуйста, помогите мне.