Pros y contras de SQLite y preferencias compartidas [cerrado]

156

¿Cuál es el buen mecanismo para almacenar información entre la base de datos SQLite y las preferencias compartidas?

¿Por qué usar preferencias compartidas? ¿Por qué usar sqlite? Traté de encontrar la diferencia entre ellos y cuál es el mejor mecanismo para almacenar datos, pero no puedo encontrar la respuesta adecuada en Google. Por favor, ayúdame con ejemplos y explicaciones.

android database sqlite sharedpreferences data-storage Rana.S
fuente
Depende más o menos del tipo de datos que desea almacenar. SharedPreferences permite un acceso más rápido y simple a los datos, es más cómodo de usar cuando se mantienen pequeñas cantidades de datos.
Egor
2
No almacene nada en Preferencias compartidas, excepto cadenas simples y primitivas, y si usa un archivo separado para cada uno, a pesar de los documentos, las Preferencias compartidas no son seguras para subprocesos e incluso si se usan únicamente en el subproceso principal extremadamente propensos a la corrupción si almacena más de 1 par de valores clave en un archivo.
RunLoop
SharedPreferences se almacenan en la memoria caché después del primer uso, por lo que deberían ser bastante rápidos en los usos de lectura consecuentes.
Stan

Respuestas:

169

Realmente depende de los datos que desea almacenar.

SQLite

Grandes cantidades de los mismos datos estructurados deben almacenarse en una base de datos SQLite ya que las bases de datos están diseñadas para este tipo de datos. A medida que la base de datos estructura y administra los datos, se puede consultar para obtener un subconjunto de datos que coincida con ciertos criterios utilizando un lenguaje de consulta como SQL. Esto permite buscar en los datos. Por supuesto, administrar y buscar grandes conjuntos de datos influye en el rendimiento, por lo que leer datos de una base de datos puede ser más lento que leer datos de SharedPreferences.

Preferencias compartidas

SharedPreferences es un almacén de clave / valor donde puede guardar datos bajo cierta clave. Para leer los datos de la tienda, debe conocer la clave de los datos. Esto hace que leer los datos sea muy fácil. Pero tan fácil como es almacenar una pequeña cantidad de datos, tan difícil como almacenar y leer datos estructurados grandes, ya que necesita definir la clave para cada uno de los datos, además, realmente no puede buscar dentro de los datos, excepto que tiene un cierto concepto para nombrando las llaves.

Flo
fuente
24
Para dar un ejemplo, SharedPreferences es útil para almacenar las preferencias del usuario, donde solo hay un puñado de variables que necesitan almacenamiento. SQLite, por otro lado, sería mejor para almacenar datos donde hay un gran conjunto de elementos, como títulos de canciones en una biblioteca de música que deben buscarse.
CL22
55
No necesita saber los nombres clave para usar SharedPreferences. Ver getAll ().
ZaBlanc
55
Para su información, hay una TERCERA opción: leer / escribir XML en un archivo. (Ver clases android.util.xml). Apropiado para datos moderadamente complejos que se pueden leer / escribir de una vez. Por ejemplo, una cuadrícula de valores que el usuario no cambia con frecuencia. Especialmente si se trata de datos que luego podría enviar a otro lugar, por lo que los necesitará en un formato analizable.
ToolmakerSteve
1
¿Es aconsejable guardar un json como cadena json en pref compartido?
Kaveesh Kanwal
2
@JCarlos Mientras no esté haciendo algunas cosas de proceso cruzado, estará bien usando SharedPreferences.
Mygod
97

Esta pregunta tiene una respuesta aceptada, pero creo que hay más que decir sobre el tema: con respecto a la velocidad.

SharedPreferences y Sqlite DB de una aplicación son solo archivos, almacenados en los directorios de la aplicación en el sistema de archivos del dispositivo. Si la cantidad de datos no es demasiado grande, la opción Sqlite implicará un archivo más grande y más complicado con más sobrecarga de procesamiento para un acceso simple.

Por lo tanto, si la naturaleza de los datos no dicta su elección (como se explica en la respuesta aceptada) y la velocidad es importante, entonces probablemente sea mejor usar SharedPreferences.

Y leer algunos datos a menudo es una ruta crítica para mostrar la actividad principal, por lo que creo que la velocidad a menudo es muy importante.

Una última reflexión con respecto a la velocidad y la eficiencia: si necesita usar una base de datos Sqlite para algunos datos estructurados, entonces probablemente sea más eficiente también almacenar las preferencias del usuario en la base de datos para no abrir un segundo archivo. Esta es una consideración bastante menor, probablemente valga la pena considerarla solo si necesita acceder tanto a los datos estructurados como a las preferencias antes de poder mostrar la actividad principal.

Tom
fuente
66
¿Qué pasa con la legibilidad del código? Creo que al almacenar múltiples registros en SharedPrefs en lugar de una tabla db, el código se vuelve complicado. La sintaxis SQL es más fácil de leer que recorrer las entradas SharedPrefs ...
IgorGanapolsky
8
Igor, no estoy de acuerdo. SharedPreferences son realmente unidimensionales, es muy sencillo usar una preferencia. Por ejemplo, estoy creando una aplicación de verificación de stock, simplemente estoy almacenando los símbolos de stock en las preferencias. No necesito tomarlos individualmente, ya que siempre los enumero a todos, y esto es todo lo que hago, guardo o agarro. Es tan simple, mucho más simple que usar un DB.
AutoM8R
1
No puedo pensar en una situación en la que la legibilidad del código sea difícil, mientras que la estructura de los datos que se guardarán no exigen el uso de una base de datos jerárquica. Incluso si hay problemas de legibilidad, se puede resolver mediante el uso de una clase de contenedor con las funciones requeridas.
Sarath Sadasivan Pillai
1
¿Podemos almacenar múltiples valores-clave en forma de datos jsonstring bajo preferencias compartidas? ¿Hay un límite de caracteres que pueda truncar mis valores json?
Nova
2
SharedPreferences se cargan en la memoria solo una vez (por ciclo de vida del proceso de la aplicación) y se mantienen allí; después de eso siempre es súper rápido. Por lo tanto, no hay realmente ninguna ganancia práctica de rendimiento al poner los datos de SharedPref en SQLite (solo para evitar el acceso adicional a los archivos de SharedPref). Y, por cierto, no deberías poner tus cosas de SQLite en SharedPrefs; como dije, siempre está en la memoria, lo que podría causarle problemas (sin memoria).
Zsolt Safrany
20

Mi opinión es que no se trata de velocidad o tamaño, sino del tipo de operación que desea hacer con sus datos.

Si usted planea hacer unirse a , tipo , y otras operaciones de base de datos en sus datos y luego ir a SQLite . Un ejemplo es ordenar los datos por fecha.

Si desea asignar valores simples (como int, boolean, String), use Preferencias . Las operaciones de DB no funcionarán aquí y no hace falta decir que necesita tener todas las claves. Un ejemplo es la contraseña de usuario o la configuración de la aplicación.

La gran tentación de adoptar Preferencias es cuando desea usarlo para almacenar un POJO aplanado (un objeto JSON serializado) como String. Tener tal necesidad es en realidad la señal para usar Sqlite. Por qué ? Porque los datos complejos eventualmente necesitarán operaciones complejas. Imagine recuperar una entrada específica que podría manejarse con un simple "SELECCIONAR ... DONDE id = 1". En la ruta de preferencias, este será un proceso largo desde la deserialización hasta la iteración de los resultados.

inmyth
fuente
Además, SharedPreferences no admite transacciones, por lo que si necesita transacciones, use SQLite. Por ejemplo, si el usuario presiona un botón de "cerrar sesión", es posible que desee borrar varias SharedPreferencesclaves / valores a la vez (por ejemplo, las teclas usery password), de modo que esté seguro de que ambas teclas están desarmadas o ambas están configuradas.
runes
5

  • Para almacenar una gran cantidad de datos, vaya al sistema de base de datos SQLite. Esto permitirá al usuario buscar datos también.

  • Por otro lado, para almacenar una pequeña cantidad de datos, vaya a Preferencias compartidas. En este caso, un gran sistema de base de datos es innecesario. Esto permitirá al usuario simplemente guardar datos y cargarlos.

Sami Al-Jabar
fuente
1
¿300 pares clave-valor son una gran cantidad de datos? Necesito almacenarlo exactamente.
JCarlosR
1
En ese caso, debe ir a la base de datos SQLite. De lo contrario, será difícil administrar y recuperar esos 300 datos.
Sami Al-Jabar
Pero si se conocen todas las claves, ¿no será más fácil obtener los datos de las Preferencias compartidas?
Arjun
-6

Olvida SQLLite olvida SharedPreferences, usa Realm. Una solución única para todo su almacenamiento local. Puede utilizar objetos Java simples como RealmObjects y almacenar sus datos allí. Puede convertir consultas seleccionadas en archivos JSON. No es necesario analizar toda la base de datos. Consulte este enlace: https://realm.io/news/introducing-realm/

Greenspand
fuente
12
olvida todo lo que sabes sobre las fundas.
Andrew G