¿Cuándo cerrar la conexión de db en android? Cada vez que finaliza su operación o después de su aplicación, salga

Tengo una aplicación para Android que accede a sqlite3 db con frecuencia, por razones de rendimiento, por lo que siempre mantengo la conexión abierta. Pero uno de mis amigos me recomendó que abriera/cerrara la conexión en cada operación.¿Cuándo cerrar la conexión de db en android? Cada vez que finaliza su operación o después de su aplicación, salga

1) ¿Cuál es la opinión de sus colegas sobre estos dos métodos? contras Pros. 2) Hice algunas pruebas y descubrí que la conexión de base de datos no tiene demasiados gastos generales de rendimiento. ¿La sobrecarga de rendimiento de la conexión DB varía según el tamaño de la base de datos?

Fuente

2011-01-30 jim.huang

Hay una compromiss, diría, todas las actividades de tiempo con las operaciones de base de datos, no itselfs de aplicación, muere ?! – Tima

Quizás una respuesta mejor: no la cierre a menos que sea necesario. http://stackoverflow.com/a/7739454/423105 – LarsH

No conozco ninguna penalización de rendimiento en el cierre/apertura frecuente de la base de datos (independientemente de su tamaño). Creo que la respuesta a esta pregunta también depende del tipo de aplicación que está accediendo a la base de datos.

¿Realiza una "nueva consulta" de la base de datos?
Luego parece rectificado para mantenerlo abierto.

¿Buscas datos diferentes cada vez que traes algo?
De nuevo, parece razonable dejarlo abierto (ya que en su lugar no obtendrás datos en caché).

¿Hay otras aplicaciones accediendo a la misma base de datos?
Si existe un riesgo de problemas de concurrencia o bloqueo, puede ser conveniente cerrar la base de datos después de terminar de leer/escribir desde/hacia ella.

En general, diría que puede obtener más en los datos de almacenamiento en caché que dejando la base de datos abierta (y cerrándola) al optimizar el rendimiento.

Fuente

2011-01-30 09:57:40 dbm

Gracias dbm. Mi aplicación es la única que accede a la base de datos y realizó muchas consultas. Parece que para mí mantener siempre abierta la base de datos es la mejor opción. Pero, ¿podría ser más específico sobre la ganancia de rendimiento al "Caché de datos", no estoy muy seguro de lo que la base de datos sqlite hizo bajo tierra. –

Supongo (quizás erróneamente) que consulta la base de datos, lee los valores que necesita del objeto Cursor devuelto y luego los descarta. La próxima vez que necesite la información, vuelva a realizar el mismo procedimiento. Ahora, suponga que la naturaleza de los datos recuperados no requeriría que la actualice entre las consultas consecutivas de la base de datos. Entonces sería una alternativa leer de la base de datos una vez y almacenar los valores en un HashMap local o algo así. El acceso a una estructura de datos "en memoria" (los datos "en caché") generalmente es mucho más rápido que volver a consultar la base de datos. – dbm

Ahora hay situaciones en las que realmente necesita volver a consultar los datos (por lo tanto, el almacenamiento en caché no es necesariamente una opción). Entonces podría ser interesante echarle un vistazo a "indexación", incluso las "declaraciones preparadas" pueden ser de interés cuando el motor de base de datos lo admite. Este enlace también puede ser interesante: http://web.utk.edu/~jplyon/sqlite/SQLite_optimization_FAQ.html – dbm

Si está utilizando una base de datos en memoria, sus datos se descartarán al cerrar la conexión.

Un poco de borde tal vez, pero me sorprendió.

Fuente

2012-02-07 10:21:55

Esta es realmente una muy buena respuesta para saber. Recientemente tuve una experiencia exitosa con el uso de una base de datos en memoria como una infraestructura de caché (donde explícitamente quería descartar el caché al salir) ... – dbm

Una vez que abre la conexión db /, ya está en la memoria caché. – zgulser

Como una adición, abrir & tan frecuentemente puede causarle la experiencia de notorias excepciones de SQLite, si accede a db desde múltiples hilos.

Consulte, si accede a db desde varios subprocesos incluso a través de una sola conexión y dado que esas operaciones no son atómicas, entonces puede intentar actualizar db que fue cerrado justo antes por otro subproceso.

Fuente

2016-01-06 07:45:52 zgulser

La documentación dice que la conexión puede estar abierta todo el tiempo que la necesite. Y se puede cerrar en el método Destroy(). Documentation link

La persistencia de conexión de base de datos:

Desde getWritableDatabase() y getReadableDatabase() son caros de llamada cuando la base de datos está cerrado, debe dejar su conexión a la base de datos abierta durante el tiempo que le sea necesario para acceder a ella Normalmente, es óptimo cerrar la base de datos en onDestroy() de la actividad de llamada.

@Override 
    protected void onDestroy() { 
     mDbHelper.close(); 
     super.onDestroy(); 
    }

Fuente

2017-05-19 06:58:28 Seagull

¿Cuándo cerrar la conexión de db en android? Cada vez que finaliza su operación o después de su aplicación, salga

Respuesta

Cuestiones relacionadas