Plusy i minusy SQLite i Shared Preferences [zamknięte]

155

Jaki jest dobry mechanizm przechowywania informacji w bazie danych SQLite i preferencjach współdzielonych?

Dlaczego warto używać wspólnych preferencji? Dlaczego warto korzystać z sqlite? Próbowałem znaleźć różnicę między nimi i który jest lepszym mechanizmem przechowywania danych, ale nie mogę znaleźć odpowiedniej odpowiedzi w Google. Proszę o pomoc w postaci przykładu i wyjaśnień.

— Rana.S
źródło

W dużym stopniu zależy to od rodzaju danych, które chcesz przechowywać. SharedPreferences pozwala na szybszy i prostszy dostęp do danych, jest wygodniejszy w użyciu przy przechowywaniu niewielkich ilości danych.

— Egor

2

Nie przechowuj niczego w Preferencjach współdzielonych z wyjątkiem prostych ciągów i prymitywów - a jeśli używasz osobnego pliku dla każdego z nich - pomimo dokumentów Preferencje współdzielone nie są bezpieczne dla wątków i nawet jeśli są używane wyłącznie w głównym wątku, są bardzo podatne na uszkodzenie, jeśli przechowujesz więcej niż 1 para klucz-wartość w pliku.

— RunLoop

SharedPreferences są buforowane w pamięci po pierwszym użyciu, więc powinny być dość szybkie przy kolejnych zastosowaniach do odczytu.

— Stan

168

To naprawdę zależy od danych, które chcesz przechowywać.

SQLite

Duże ilości takich samych danych strukturalnych powinny być przechowywane w bazie danych SQLite, ponieważ bazy danych są zaprojektowane dla tego rodzaju danych. Ponieważ dane są ustrukturyzowane i zarządzane przez bazę danych, można zapytać o podzbiór danych, które pasują do określonych kryteriów, przy użyciu języka zapytań, takiego jak SQL. Umożliwia to przeszukiwanie danych. Oczywiście zarządzanie i wyszukiwanie dużych zbiorów danych wpływa na wydajność, więc odczyt danych z bazy danych może być wolniejszy niż odczyt danych z SharedPreferences.

SharedPreferences

SharedPreferences to magazyn kluczy / wartości, w którym można zapisać dane pod określonym kluczem. Aby odczytać dane ze sklepu, musisz znać klucz danych. To sprawia, że odczyt danych jest bardzo łatwy. Ale tak proste, jak przechowywanie niewielkiej ilości danych jest tak trudne, jak przechowywanie i odczytywanie dużych danych strukturalnych, ponieważ trzeba zdefiniować klucz dla wszystkich danych, ponadto nie można tak naprawdę wyszukiwać w danych, chyba że masz określoną koncepcję nazywanie kluczy.

— Flo
źródło

24

Na przykład, SharedPreferences są przydatne do przechowywania preferencji użytkownika, w których istnieje tylko kilka zmiennych, które wymagają przechowywania. Z drugiej strony SQLite byłby lepszy do przechowywania danych, w których znajduje się duży zestaw elementów, takich jak tytuły utworów w bibliotece muzycznej, które należy przeszukać.

— CL22

5

Nie musisz znać nazw kluczy, aby używać SharedPreferences. Zobacz getAll ().

— ZaBlanc

5

FYI, istnieje TRZECIA opcja: odczyt / zapis XML do pliku. (Zobacz klasy android.util.xml). Odpowiedni dla średnio złożonych danych, które można odczytać / zapisać jednocześnie. Na przykład siatka wartości, których użytkownik nie zmienia często. Zwłaszcza jeśli są to dane, które możesz później chcieć wysłać gdzie indziej, więc będą potrzebne w formacie możliwym do przeanalizowania.

— ToolmakerSteve

1

czy wskazane jest zapisanie json jako łańcucha json we współdzielonym pref?

— Kaveesh Kanwal

2

@JCarlos Dopóki nie wykonujesz pewnych czynności międzyprocesowych, będziesz dobrze używać SharedPreferences.

— Mygod

96

To pytanie ma akceptowaną odpowiedź, ale myślę, że na ten temat można powiedzieć więcej - o szybkości.

SharedPreferences aplikacji i Sqlite DB to tylko pliki przechowywane w katalogach aplikacji w systemie plików urządzenia. Jeśli ilość danych nie jest zbyt duża, opcja Sqlite będzie obejmować większy i bardziej skomplikowany plik z większym obciążeniem przetwarzania w celu ułatwienia dostępu.

Tak więc, jeśli charakter danych nie determinuje Twojego wyboru (jak wyjaśniono w zaakceptowanej odpowiedzi), a szybkość ma znaczenie, prawdopodobnie lepiej jest użyć SharedPreferences.

Czytanie niektórych danych często znajduje się na krytycznej ścieżce do wyświetlenia głównej czynności, więc myślę, że szybkość jest często bardzo ważna.

Ostatnia myśl dotycząca szybkości i wydajności - jeśli potrzebujesz użyć bazy danych Sqlite dla niektórych ustrukturyzowanych danych, prawdopodobnie bardziej wydajne jest przechowywanie w bazie danych preferencji użytkownika, aby nie otwierać drugiego pliku. Jest to dość drobna uwaga - prawdopodobnie warta rozważenia tylko wtedy, gdy musisz uzyskać dostęp zarówno do danych strukturalnych, jak i preferencji, zanim będziesz mógł wyświetlić główną aktywność.

— Tomek
źródło

6

A co z czytelnością kodu? Myślę, że podczas przechowywania wielu rekordów w SharedPrefs zamiast tabeli db, kod staje się zagmatwany. Składnia Sql jest łatwiejsza do odczytania niż zapętlanie wpisów

— SharedPrefs

8

Igor, nie zgodziłbym się. SharedPreferences są naprawdę 1-wymiarowe, bardzo proste jest ich użycie. Na przykład, tworzę aplikację do sprawdzania zapasów, po prostu przechowuję symbole giełdowe w preferencjach. Nie muszę brać ich pojedynczo, ponieważ zawsze wymieniam je wszystkie i to wszystko, co robię, przechowuję lub chwytam. To takie proste, znacznie prostsze niż używanie bazy danych.

— AutoM8R

1

Nie przychodzi mi do głowy sytuacja, w której czytelność kodu jest utrudniona, a struktura zapisywanych danych nie wymaga stosowania hierarchicznej bazy danych. Nawet jeśli występują problemy z czytelnością, można je rozwiązać za pomocą klasy opakowującej z wymaganymi funkcjami.

— Sarath Sadasivan Pillai

1

Czy możemy przechowywać wiele par klucz-wartość w postaci danych jsonstring w ramach wspólnych preferencji? Czy istnieje limit znaków, który może spowodować obcięcie moich wartości json?

— Nova,

2

SharedPreferences są ładowane do pamięci tylko raz (na cykl życia aplikacji) i tam przechowywane; potem zawsze jest super szybko. Więc tak naprawdę nie ma żadnej praktycznej korzyści dla wydajności, umieszczając dane SharedPref w SQLite (tylko po to, aby uniknąć dodatkowego dostępu do plików SharedPref). A tak przy okazji, nie powinieneś umieszczać swoich danych SQLite w SharedPrefs; jak powiedziałem, zawsze jest w pamięci, co może powodować problemy (te związane z brakiem pamięci).

— Zsolt Safrany

20

Moim zdaniem nie chodzi o szybkość ani rozmiar, ale rodzaj operacji, które chcesz wykonać na swoich danych.

Jeśli planujesz zrobić przyłączyć , porządek , i inne operacje DB na danych a następnie przejść do Sqlite . Przykładem jest sortowanie danych według daty.

Jeśli chcesz odwzorować proste wartości (takie jak int, boolean, String), użyj Preferencji . Operacje bazy danych nie będą tutaj działać i nie trzeba dodawać, że musisz mieć wszystkie klucze. Przykładem jest hasło użytkownika lub konfiguracja aplikacji.

Wielką pokusą przyjęcia Preferencji jest to, że chcesz go użyć do przechowywania spłaszczonego POJO (serializowanego obiektu JSON) jako String. Posiadanie takiej potrzeby jest właściwie znakiem do korzystania z Sqlite. Czemu ? Ponieważ złożone dane będą ostatecznie wymagały skomplikowanych operacji. Wyobraź sobie, że pobierasz konkretny wpis, który mógłby być obsługiwany przez proste „SELECT ... WHERE id = 1”. Na ścieżce Preferencje będzie to długi proces od deserializacji do iteracji wyników.

— inmyth
źródło

Ponadto SharedPreferences nie obsługuje transakcji, więc jeśli potrzebujesz transakcji, użyj SQLite. Na przykład, jeśli użytkownik naciśnie przycisk „wyloguj się”, możesz chcieć wyczyścić wiele SharedPreferenceskluczy / wartości naraz (np. Oba klucze useri password), aby mieć pewność, że oba klucze są nieustawione lub oba są ustawione.

— runeks

5

Do przechowywania dużej ilości danych wybierz system bazodanowy SQLite. Umożliwi to użytkownikowi wyszukiwanie danych.
Z drugiej strony, aby przechowywać niewielką ilość danych, przejdź do Preferencji wspólnych. W takim przypadku ogromny system baz danych jest zbędny. Pozwoli to użytkownikowi po prostu zapisać dane i załadować je.

— Sami Al-Jabar
źródło

1

300 par klucz-wartość to ogromna ilość danych? Muszę to dokładnie przechowywać.

— JCarlosR

1

W takim przypadku powinieneś wybrać bazę danych SQLite. W przeciwnym razie zarządzanie tymi 300 danymi i ich odzyskanie będzie trudne.

— Sami Al-Jabar

Ale jeśli wszystkie klucze są znane, czy nie będzie łatwiej pobrać dane ze wspólnych preferencji?

— Arjun

-6

Zapomnij o SQLLite, zapomnij o SharedPreferences, użyj Realm. Jedno rozwiązanie dla całej Twojej lokalnej pamięci. Możesz używać zwykłych starych obiektów Java jako RealmObjects i przechowywać tam swoje dane. Możesz przekonwertować wybrane zapytania na pliki JSON. Nie ma potrzeby analizowania całej bazy danych. Sprawdź ten link: https://realm.io/news/introducing-realm/

— greenspand
źródło

12

zapomnij o wszystkim, co wiesz o pokrowcach.

— Andrew G,