Avantages et inconvénients de SQLite et des préférences partagées [fermé]

156

Quel est le bon mécanisme pour stocker des informations dans la base de données SQLite et les préférences partagées?

Pourquoi utiliser des préférences partagées? Pourquoi utiliser sqlite? J'ai essayé de trouver la différence entre eux et quel est le meilleur mécanisme de stockage des données, mais je ne parviens pas à trouver la réponse appropriée sur Google. Veuillez m'aider avec des exemples et des explications.

— Rana.S
source

Cela dépend en grande partie du type de données que vous souhaitez stocker. SharedPreferences permet un accès plus rapide et plus simple aux données, il est plus confortable à utiliser lors de la conservation de petites quantités de données.

— Egor

2

Ne stockez rien dans les préférences partagées à l'exception des chaînes simples et des primitives - et si vous utilisez un fichier séparé pour chacune - malgré la documentation, les préférences partagées ne sont pas thread-safe et même si elles sont utilisées uniquement sur le thread principal extrêmement sujettes à la corruption si vous en stockez plus plus d'une paire clé / valeur dans un fichier.

— RunLoop

Les SharedPreferences sont mises en cache en mémoire après la première utilisation, elles devraient donc être assez rapides pour les utilisations Read conséquentes.

— Stan

169

Cela dépend vraiment des données que vous souhaitez stocker.

SQLite

De grandes quantités de mêmes données structurées doivent être stockées dans une base de données SQLite car les bases de données sont conçues pour ce type de données. Comme les données sont structurées et gérées par la base de données, elles peuvent être interrogées pour obtenir un sous-ensemble de données qui correspond à certains critères en utilisant un langage de requête comme SQL. Cela permet de rechercher dans les données. Bien sûr, la gestion et la recherche de grands ensembles de données influent sur les performances, de sorte que la lecture de données à partir d'une base de données peut être plus lente que la lecture de données à partir de SharedPreferences.

Préférences partagées

SharedPreferences est un magasin de clés / valeurs dans lequel vous pouvez enregistrer des données sous certaines clés. Pour lire les données du magasin, vous devez connaître la clé des données. Cela rend la lecture des données très facile. Mais aussi simple qu'il soit de stocker une petite quantité de données, aussi difficile qu'il soit de stocker et de lire de grandes données structurées car vous devez définir la clé pour chaque donnée, en outre, vous ne pouvez pas vraiment rechercher dans les données sauf si vous avez un certain concept pour nommer les clés.

— Flo
source

24

Pour donner un exemple, SharedPreferences est utile pour stocker les préférences de l'utilisateur, où il n'y a qu'une poignée de variables à stocker. SQLite, d'un autre côté, serait préférable pour stocker des données dans lesquelles il existe un grand nombre d'éléments, tels que les titres de chansons dans une bibliothèque musicale, qui doivent être recherchés.

— CL22

5

Vous n'avez pas besoin de connaître les noms de clé pour utiliser SharedPreferences. Voir getAll ().

— ZaBlanc

5

Pour info, il existe une TROISIÈME option: lire / écrire du XML dans un fichier. (Voir les classes android.util.xml). Convient aux données moyennement complexes qui peuvent être lues / écrites en une seule fois. Par exemple, une grille de valeurs que l'utilisateur ne modifie pas fréquemment. Surtout si ce sont des données que vous voudrez peut-être envoyer plus tard ailleurs, elles auront donc besoin d'un format analysable.

— ToolmakerSteve

1

est-il conseillé d'enregistrer un json en tant que chaîne json dans shared pref?

— Kaveesh Kanwal

2

@JCarlos Tant que vous n'effectuez pas de travail croisé, tout ira bien en utilisant SharedPreferences.

— Mygod

97

Cette question a une réponse acceptée, mais je pense qu'il y a plus à dire sur le sujet - concernant la vitesse.

Les SharedPreferences et Sqlite DB d'une application ne sont que des fichiers, stockés dans les répertoires de l'application sur le système de fichiers du périphérique. Si la quantité de données n'est pas trop grande, l'option Sqlite impliquera un fichier plus volumineux et plus compliqué avec plus de temps de traitement pour un accès simple.

Donc, si la nature des données ne dicte pas votre choix (comme expliqué dans la réponse acceptée) et que la vitesse compte, il vaut probablement mieux utiliser SharedPreferences.

Et la lecture de certaines données est souvent sur le chemin critique pour afficher l'activité principale, donc je pense que la vitesse est souvent très importante.

Une dernière réflexion concernant la vitesse et l'efficacité - si vous devez utiliser une base de données Sqlite pour certaines données structurées, il est probablement plus efficace de stocker également les préférences de l'utilisateur dans la base de données afin de ne pas ouvrir un deuxième fichier. Il s'agit d'une considération assez mineure - qui ne vaut probablement la peine d'être prise en considération que si vous devez accéder à la fois aux données structurées et aux préférences avant de pouvoir afficher l'activité principale.

— À M
source

6

Qu'en est-il de la lisibilité du code? Je pense que lors du stockage de plusieurs enregistrements dans SharedPrefs au lieu d'une table db, le code devient alambiqué. La syntaxe SQL est plus facile à lire que la boucle sur les entrées SharedPrefs ...

— IgorGanapolsky

8

Igor, je ne suis pas d'accord. Les préférences partagées sont vraiment unidimensionnelles, il est très simple d'utiliser une préférence. Par exemple, je crée une application de vérification des stocks, je stocke simplement les symboles boursiers dans les préférences. Je n'ai pas besoin de les attraper individuellement, car je les énumère toujours tous, et c'est tout ce que je fais, stocke ou saisis. C'est tellement simple, beaucoup plus simple que d'utiliser une base de données.

— AutoM8R

1

Je ne peux pas penser à une situation où la lisibilité du code devient difficile alors que la structure des données à sauvegarder ne nécessite pas l'utilisation d'une base de données hiérarchique. Même s'il y a des problèmes de lisibilité, ils peuvent être résolus en utilisant une classe wrapper avec les fonctions requises.

— Sarath Sadasivan Pillai

1

Pouvons-nous stocker plusieurs valeurs-clés sous la forme de données jsonstring sous des préférences partagées? Y a-t-il une limite de caractères qui peut tronquer mes valeurs json?

— Nova du

2

Les SharedPreferences ne sont chargées dans la mémoire qu'une seule fois (par cycle de vie du processus d'application) et y sont conservées; après ça c'est toujours super rapide. Il n'y a donc pas vraiment de gain de performance pratique en mettant des données SharedPref dans SQLite (juste pour éviter un accès supplémentaire aux fichiers SharedPref). Et au fait, vous ne devriez pas mettre vos trucs SQLite dans SharedPrefs; comme je l'ai dit, c'est toujours en mémoire ce qui peut vous causer des problèmes (ceux qui manquent de mémoire).

— Zsolt Safrany

20

Mon opinion est que ce n'est pas une question de vitesse ou de taille, mais les types d'opérations que vous souhaitez effectuer sur vos données.

Si vous envisagez de faire adhérer , sorte , et d' autres opérations de DB sur vos données vont alors pour SQLite . Un exemple est le tri des données par date.

Si vous souhaitez mapper des valeurs simples (comme int, boolean, String), utilisez Préférences . Les opérations DB ne fonctionneront pas ici et il va sans dire que vous devez avoir toutes les clés. Un exemple est le mot de passe utilisateur ou la configuration de l'application.

La grande tentation d'adopter les préférences est lorsque vous souhaitez l'utiliser pour stocker un POJO aplati (un objet JSON sérialisé) sous forme de chaîne. Avoir un tel besoin est en fait le signe d'utiliser Sqlite. Pourquoi ? Parce que les données complexes nécessiteront éventuellement des opérations complexes. Imaginez récupérer une entrée spécifique qui pourrait être gérée par un simple "SELECT ... WHERE id = 1". Dans le chemin des préférences, ce sera un long processus allant de la désérialisation à l'itération des résultats.

— inmyth
source

De plus, SharedPreferences ne prend pas en charge les transactions, donc si vous avez besoin de transactions, utilisez SQLite. Par exemple, si l'utilisateur appuie sur un bouton de "déconnexion", vous souhaiterez peut-être effacer plusieurs SharedPreferencesclés / valeurs à la fois (par exemple les touches useret password), afin d'être sûr que les deux clés sont désactivées ou les deux sont définies.

— runeks

5

Pour stocker une énorme quantité de données, optez pour le système de base de données SQLite. Cela permettra également à l'utilisateur de rechercher des données.
D'autre part, pour stocker une petite quantité de données, optez pour les préférences partagées. Dans ce cas, un énorme système de base de données n'est pas nécessaire. Cela permettra à l'utilisateur de simplement enregistrer les données et de les charger.

— Sami Al-Jabar
source

1

300 paires clé-valeur, c'est une énorme quantité de données? J'ai besoin de le stocker exactement.

— JCarlosR

1

Dans ce cas, vous devriez opter pour la base de données SQLite. Sinon, il sera difficile de gérer et de récupérer ces 300 données.

— Sami Al-Jabar

Mais si toutes les clés sont connues, ne sera-t-il pas plus facile d'extraire les données des préférences partagées?

— Arjun

-6

Oubliez SQLLite, oubliez SharedPreferences, utilisez Realm. Une solution unique pour tout votre stockage local. Vous pouvez utiliser d'anciens objets Java simples comme RealmObjects et y stocker vos données. Vous pouvez convertir les requêtes sélectionnées en fichiers JSON. Pas besoin d'analyser toute la base de données. Vérifiez ce lien: https://realm.io/news/introducing-realm/

— greenspand
source

12

oubliez tout ce que vous savez sur les housses.

— Andrew G