2012-04-29 15 views
9

Estoy trabajando en un proyecto que requiere almacenar bitmaps en una tabla. Estos mapas de bits se usan en adaptadores de datos para mostrarse en listas. Esta tabla posiblemente puede contener más de 1000 imágenes. La razón por la que actualmente no guardo para archivar es por la rapidez con la que puedo leer y escribir imágenes en db.¿Cómo funciona un cursor SQLite internamente?

Lo que básicamente busco es comprender las limitaciones del cursor de SQLite. ¿Cómo se carga el cursor en la memoria? ¿Coloca los resultados de la consulta en la memoria o crea algún tipo de archivo de lectura/escritura temporal? No quiero encontrarme con problemas en los que la consulta de grandes conjuntos de datos hace que un dispositivo se quede sin memoria.

+0

Hay [CursorWindow] (http://developer.android.com/reference/android/database/CursorWindow.html) y parece ser un usado para cargar solo partes de la consulta cada vez que 'moveToXyz'. Los datos deben venir directamente de la base de datos. – zapl

+0

"Estoy trabajando en un proyecto que requiere almacenar mapas de bits en una tabla". - ick. "Esta tabla posiblemente puede contener más de 1000 imágenes". - más ick. "La razón por la que actualmente no estoy almacenando en el archivo es por la rapidez con que puedo leer y escribir imágenes en db". - por definición, un archivo será tan rápido o más rápido, ya que SQLite tiene que almacenar sus cosas en un archivo. – CommonsWare

+0

zapl gracias por esa información. @CommonsWare No estoy seguro de lo que significa ick: P Creo que parece que debe ser rápido o más rápido para leer del archivo que db. No sé mucho sobre los cursores que no sea cómo usarlos ... ¿pero SQLite no optimiza mucho cómo lees de sus datos? Quiero decir que leer datos de imágenes del archivo varias veces parece ser mucho más lento que leerlos desde un cursor. – Jona

Respuesta

0

Esta es una publicación anterior que hice. Mi solución fue guardar imágenes en un archivo y guardar la ruta a la imagen en la tabla de la base de datos. Esto era más limpio y parecía mucho más rápido.

La idea de guardar datos binarios grandes en una tabla no parece lo correcto. No tengo información detallada sobre por qué no es una buena idea, pero así es como me siento de un poco de investigación.

1

Si lo recuerdo, guardará todos los resultados almacenados en memoria caché. Debería mantenerse por debajo del soft heap limit, por lo general. Es un límite de asesoramiento, por lo que preferirá ir más allá del límite que devolver SQL_NOMEM.

No creo que escriba en el disco para ningún mecanismo de caché. Mientras que cada imagen pueda caber en la memoria, y no estén en los índices, no debería ser un problema.

No soy un programador de Android, por lo que vale la pena. Algunas de estas cosas podrían haber sido personalizadas.

Como fondo, sqlite_step es el cursor en la biblioteca predeterminada. No sé si Android ha implementado sus propios mecanismos. Puede encontrar información general en su página acerca de dynamic memory allocation.

Cuestiones relacionadas