Плюси і мінуси налаштування SQLite та спільних налаштувань [закрито]

156

Який хороший механізм зберігання інформації серед баз даних SQLite та спільних налаштувань?

Навіщо використовувати спільні налаштування? Навіщо використовувати sqlite? Я намагався знайти різницю між ними, і який є кращим механізмом зберігання даних, але мені не вдається знайти відповідну відповідь в Google. Будь ласка, допоможіть мені із прикладом та поясненнями.

android  database  sqlite  sharedpreferences  data-storage 
— Рана.С
джерело
Це в значній мірі залежить від типу даних, які ви хочете зберігати. SharedPreferences дозволяє швидше і простіше отримати доступ до даних, зручніше користуватися при збереженні невеликої кількості даних.
— Єгор
2
Не зберігайте нічого в спільних налаштуваннях, окрім простих рядків та примітивів - і якщо ви використовуєте окремий файл для кожного - незважаючи на документи, спільні налаштування не є безпечними для потоків, і навіть якщо вони використовуються виключно на головному потоці, надзвичайно схильному до пошкодження, якщо ви зберігаєте більше ніж одна пара ключових значень у файлі.
— RunLoop
SharedPreferences зберігаються в пам'яті після першого використання, тому вони повинні бути досить швидкими при послідовних програмах Read.
— Стен

Відповіді:

169

Це дійсно залежить від даних, які ви хочете зберігати.

SQLite

Велика кількість однакових структурованих даних повинна зберігатися в базі даних SQLite, оскільки бази даних призначені для такого типу даних. Оскільки дані структуруються та керуються базою даних, її можна запитувати, щоб отримати підмножину даних, яка відповідає певним критеріям, використовуючи мову запитів, як SQL. Це дає можливість здійснювати пошук у даних. Звичайно, керування та пошук великих наборів даних впливає на продуктивність, тому читання даних із бази даних може бути повільніше, ніж читання даних із SharedPreferences.

SharedPreferences

SharedPreferences - це сховище ключів / цінностей, де ви можете зберігати дані під певним ключем. Щоб прочитати дані з магазину, ви повинні знати ключ даних. Це робить читання даних дуже простим. Але настільки ж просто, як зберігати невеликий обсяг даних так само складно, як зберігати та читати великі структуровані дані, оскільки вам потрібно визначити ключ для кожної окремо взятої інформації, крім того, ви не можете реально шукати дані, за винятком того, що у вас є певна концепція для називання ключів.

— Flo
джерело
24
Для прикладу, SharedPreferences корисні для зберігання налаштувань користувача, де є лише кілька змінних, які потребують зберігання. З іншого боку, SQLite буде кращим для зберігання даних там, де в музичній бібліотеці є великий набір елементів, таких як назви пісень, які потребують пошуку.
— CL22
5
Вам не потрібно знати імена ключів, щоб використовувати SharedPreferences. Дивіться getAll ().
— ZaBlanc
5
FYI, є ТРЕТИЙ варіант: читати / записувати XML у файл. (Див. Класи для android.util.xml). Підходить для помірно складних даних, які можна прочитати / записати все одночасно. Наприклад, сітка значень, яку користувач не змінює часто. Особливо, якщо це дані, які згодом ви можете надіслати деінде, тому вони знадобляться у розбірливому форматі.
— ToolmakerSteve
1
чи доцільно зберегти json як json рядок у спільному префіксі?
— Kaveesh Kanwal
2
@JCarlos До тих пір, поки ви не будете робити якісь перехресні процеси, ви будете добре використовувати SharedPreferences.
— Mygod
97

На це питання є прийнята відповідь, але я думаю, що на тему можна сказати більше - щодо швидкості.

SharedPreferences програми та БД Sqlite - це просто файли, що зберігаються в каталогах програми у файловій системі пристрою. Якщо кількість даних не надто велика, параметр Sqlite буде містити більший і складніший файл з більшою кількістю накладних витрат для простого доступу.

Отже, якщо природа даних не диктує ваш вибір (як пояснено у прийнятій відповіді), а швидкість має значення, то вам, ймовірно, краще скористатися SharedPreferences.

І читання деяких даних часто перебуває на найважливішому шляху до відображення основної активності, тому я думаю, що швидкість дуже важлива.

Остання заключна думка щодо швидкості та ефективності - якщо вам потрібно використовувати базу даних Sqlite для деяких структурованих даних, то, ймовірно, більш ефективно також зберігати налаштування користувачів у базі даних, щоб ви не відкривали другий файл. Це досить незначне враження - можливо, варто розглянути лише у тому випадку, якщо вам потрібно отримати доступ до структурованих даних та налаштувань, перш ніж ви зможете відобразити основну діяльність.

— Том
джерело
6
Що з читабельністю коду? Я думаю, що при зберіганні декількох записів у SharedPrefs замість таблиці db код стає викривленим. Синтаксис Sql легше читати, ніж перебирати записи на SharedPrefs ...
— IgorGanapolsky
8
Ігоре, я не погодився б. SharedPreferences дійсно є одновимірним, користуватися перевагою дуже просто. Наприклад, я будую додаток для перевірки запасів, я просто зберігаю символи запасів у преференціях. Мені не потрібно хапати їх окремо, так як я завжди перераховую всі, і це все, що я роблю, зберігаю або захоплюю. Це так просто, набагато простіше, ніж використання БД.
— AutoM8R
1
Я не можу придумати ситуацію, коли читабельність коду стає важкою, тоді як структура даних, що зберігаються, не вимагає використання ієрархічної бази даних. Навіть якщо є якісь проблеми читабельності, це можна вирішити за допомогою класу обгортки з необхідними функціями.
— Сарат Садасіван Піллай
1
Чи можемо ми зберігати кілька ключових значень у вигляді даних jsonstring під спільними налаштуваннями? Чи є обмеження символів, яке може усікати мої значення json?
— Нова
2
SharedPreferences завантажуються в пам'ять лише один раз (за життєвий цикл програми) і зберігаються там; після цього завжди супер швидко. Таким чином, насправді не виграє практична продуктивність, вводячи дані SharedPref в SQLite (лише заради уникнення додаткового доступу до файлів SharedPref). І до речі, ви не повинні ставити свої речі SQLite в SharedPrefs; як я вже говорив, це завжди в пам'яті, що може викликати у вас проблеми (поза пам'яттю).
— Zsolt Safrany
20

Я вважаю, що справа не в швидкості чи розмірі, а в операціях, які ви хочете зробити зі своїми даними.

Якщо ви плануєте зробити приєднатися , свого роду , і інші операції БД на даних потім піти на Sqlite . Прикладом є сортування даних за датою.

Якщо ви хочете зіставити прості значення (наприклад, int, boolean, String), тоді скористайтеся налаштуваннями . Операції з БД тут не працюватимуть, і не потрібно говорити, що вам потрібно мати всі ключі. Прикладом є пароль користувача або конфігурація програми.

Велика спокуса сприйняти налаштування - це коли ви хочете використовувати його для зберігання сплющеного POJO (серіалізованого об'єкта JSON) як String. Мати таку потребу - насправді знак використовувати Sqlite. Чому? Тому що складні дані з часом потребують складних варіантів. Уявіть, що ви отримаєте певний запис, який може бути оброблений простим "SELECT ... WHERE id = 1". На шляху налаштувань це буде довгий процес від десеріалізації до повторення результатів.

— інміт
джерело
Також SharedPreferences не підтримує транзакції, тому якщо вам потрібні транзакції, тоді використовуйте SQLite. Наприклад, якщо користувач натискає кнопку "Вийти з системи", ви, можливо, захочете очистити SharedPreferencesвідразу кілька клавіш / значень (наприклад, userі passwordклавіші та ), щоб бути впевненим, що обидві клавіші не встановлені або обидві встановлені.
— рунекс
5

  • Для зберігання величезної кількості даних перейдіть до системи баз даних SQLite. Це дозволить користувачеві також шукати дані.

  • З іншого боку, для зберігання невеликої кількості даних перейдіть до спільних налаштувань. У цьому випадку величезна система бази даних непотрібна. Це дозволить користувачеві просто зберігати дані та завантажувати їх.

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

Забудьте про SQLLite забудьте SharedPreferences, використовуйте Realm. Єдине рішення для всіх ваших локальних сховищ. Ви можете використовувати звичайні старі об’єкти Java як RealmObjects і зберігати там свої дані. Ви можете конвертувати відокремлені запити у файли JSON. Не потрібно розбирати всю базу даних. Перевірте це посилання: https://realm.io/news/introducing-realm/

— зелень
джерело
12
забудьте все, що знаєте про ковзани.
— Андрій Г
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.