Razones para utilizar la base de datos SQLite legible

La clase Android SQLiteOpenHelper tiene un método para devolver una base de datos legible y una base de datos de lectura y escritura. Actualmente solo estoy usando una base de datos con capacidad de escritura y no tengo problemas, pero me pregunto cuál sería el beneficio de cambiar a legible solo si solo estoy leyendo en una tarea (o actividad) asíncrona.Razones para utilizar la base de datos SQLite legible

Puede haber beneficios de rendimiento pero no he visto ninguna referencia a los números reales. Además, si sigo cambiando entre legible y escribible, el cambio tiene una sobrecarga que puede quitarle toda la ventaja de rendimiento.

¿Alguien tiene algún número real o experiencia con esto? ¿Vale la pena implementar un acceso separado?

Fuente

2010-12-29 Manfred Moser

En general, lo he interpretado como una medida de protección más que por el rendimiento. Se podría declarar públicas todas las clases/métodos/datos de Java, pero usamos 'protected',' private', y package-'protected' para evitar que se arruinen. Del mismo modo, una base de datos legible puede ayudar a detectar errores de codificación. Dicho esto, dado que 'SQLiteOpenHelper' actualiza de forma transparente la base de datos para que pueda escribirse en una futura llamada' getWritableDatabase() ', el valor es probablemente algo limitado. – CommonsWare

Gracias por esa pista. Creo que no voy a molestarme en esta etapa como se menciona a continuación. –

No puedo comentar sobre los beneficios de rendimiento, pero siempre trato de trabajar sobre el principio de 'buenas prácticas' (o 'mejores prácticas' incluso) para cualquier acceso a cualquier 'datos' fuentes (archivos de texto, bases de datos o lo que sea)

Observando las cosas de forma genérica (no específica de Android), las decisiones que se tomarán al decidir el nivel de acceso se reducirán a la operación que se realizará así como a las influencias externas.

Dos ejemplos que se me ocurren ...

Si un proceso externo pueden tener la responsabilidad de los datos mantenimiento - en este caso puede haber 'abierto' la fuente de datos de tal manera que bloquea todo excepto el acceso de "lectura" por cualquier otro proceso durante la fase de mantenimiento. En este caso, se negará el acceso al código si solicita acceso de lectura/escritura cuando no es necesario.
El riesgo de comprometer la integridad de los datos: piratear sistemas del mundo exterior puede lograrse a través de un agujero de seguridad que utiliza un código interno que tiene acceso de lectura/escritura a datos cuando realmente solo necesita tener acceso de "lectura".

OK, esos puntos pueden o no tener relevancia para Android (particularmente si su fuente de datos es específica de su aplicación) pero, como dije, trato de ver las cosas genéricamente y usar una 'mejor práctica' enfoque. Si no necesito acceso de "escritura", no lo solicito.

Fuente

2010-12-30 00:15:31 Squonk

Aunque estoy de acuerdo con sus puntos, no se aplican a Android en este caso. No existe un servidor db como tal, sino un archivo db único y un código de acceso (naitve y vía dalvik vm) que es exclusivo de esta aplicación. Dentro de cada aplicación, el acceso a db es exclusivo (obligatorio) y secuencial. Si otra aplicación tiene un archivo db, se trata de un archivo db independiente y de las excepciones de acceso y todas (cada aplicación tiene su propia vm). También como viste arriba en el otro comentario, el javadoc incluso dice que se devuelve el mismo objeto, por lo que todo tiene aún menos sentido. –

@Manfred Moser: Sí, soy consciente de que las aplicaciones existen dentro de tu propia VM y estoy bastante familiarizado con SQLite que no tiene servidor (he estado usando SQLite desde hace un tiempo en varias plataformas). ¿Existen todas las bases de datos SQLite 'en proceso' sin embargo? ¿Y los que se pueden crear en la tarjeta SD, por ejemplo? Además, ¿qué pasa con el acceso desde otros hilos dentro de la misma aplicación? El comentario de CommonsWare sobre que no creamos todo, ya que "público" era básicamente lo que quería decir: "mejor práctica" y todo eso. Nunca supongas que tu 'arena' nunca cambiará. – Squonk

Voy a aceptar su respuesta en esta etapa. En esta etapa, dudo que haga un esfuerzo para refactorizar, ya que en mi caso creo que el cierre y la apertura constantes reducirían el rendimiento. En términos de protección, no veo valor, ya que los datos no son críticos. –

Buena pregunta. No hay números de mi parte La explicación más cercana (de SQLLiteOpenHandler javadoc)

"Este (getReadableDatabase) será el mismo objeto devuelto por getWritableDatabase() a menos que algún problema, tal como un disco completo, requiere la base de datos para ser abierto sólo lectura. En En ese caso, se devolverá un objeto de base de datos de solo lectura. Si se soluciona el problema, una llamada futura a getWritableDatabase() puede tener éxito, en cuyo caso se cerrará el objeto de base de datos de solo lectura y se devolverá el objeto de lectura/escritura. en el futuro. "

Fuente

2010-12-30 00:12:42 GSree

Buen hallazgo e iría de alguna manera para evitar una falla en el primer punto que menciono en mi respuesta. – Squonk

@Manfred Moser Como dije en mi respuesta ... no estoy seguro si podemos probar esto de una manera u otra (es decir, tiene/no tiene una ventaja de rendimiento). Aquí hay una razón (no verificada) en la que puedo pensar que esto podría tener un impacto en el rendimiento. Si usa getWritableDatabase() necesita llamar al método close() o de lo contrario obtendrá mucho rojo en LogCat. Donde (esta parte no está verificada) getReadableDatabase() no ordena la llamada al método close(). Si su aplicación está cerrando la base de datos con frecuencia, esto podría (!) Afectar el rendimiento. – GSree

Razones para utilizar la base de datos SQLite legible

Respuesta

Cuestiones relacionadas