2011-08-11 9 views
12

Tengo una aplicación con una base de datos SQLite para almacenar información para la cuenta de un usuario. Diseñé la base de datos asumiendo que la aplicación solo tendría un usuario. Como tal, la identificación del usuario no se almacena en la base de datos (pero se almacena en una base de datos central en un servidor). Sin embargo, es posible desconectarse de la aplicación y permitir que otro usuario inicie sesión, pero el problema con esto es por el momento, sus datos se descargan y luego se anexan a los datos del otro usuario. Esto no es lo que quiero que suceda, pero no estoy seguro de cuál es la mejor manera de cambiar el diseño de la base de datos para resolverlo. Pensé en:Base de datos SQLite para la aplicación de Android con posibles usuarios múltiples

  1. Una base de datos por usuario. Podría dar lugar a un almacenamiento de datos innecesario si un usuario simplemente inicia sesión una vez en el teléfono de su amigo y nunca más. También creo que esto podría ser difícil de manejar.
  2. Agregue una columna de ID de usuario a todas las tablas, por lo que agregar no causa ningún problema. Todavía tiene el problema de datos innecesarios que (1) tiene, y pierde la modularidad de 1.
  3. Limpie la base de datos cuando el usuario cierre la sesión. Si el usuario tiene una gran cantidad de datos en el servidor, llevará mucho tiempo sincronizar los datos cuando se inicie la aplicación (esto se hará en otro hilo, pero sigue siendo un problema).

¿Es uno de estos enfoques buenos? ¿O hay una mejor manera de hacer esto?

Respuesta

3

Me gustaría ir por la opción 1. Mantenerlo como un archivo separado asegurará que no habrá ninguna implicación de rendimiento al tener múltiples bases de datos.

Puede agregar la ID de usuario al nombre de archivo de la base de datos. Podría tener algún tipo de sistema LRU donde elimine automáticamente la base de datos más antigua si tiene más de 4 (o si excede una cierta cantidad de datos).

Los detalles de esta elección dependerán de usted, ya que sabe cuánto almacenamiento de datos desea usar y cuántos usuarios probablemente usarían la aplicación en el mismo dispositivo.

+0

Me gusta el enfoque LRU: estaba pensando en hacer un seguimiento de cuándo se modificaron, pero ambas sugerencias serán más sencillas de implementar. Y realmente dudo que más de 1 usuario use la aplicación en el mismo dispositivo, ¡pero nunca se sabe! Gracias :) – Pikaling

+0

¿Cuál es en realidad la ventaja de la propuesta 1 sobre la propuesta 2 ..? ¿Qué "modularidad" se pierde? ¿Qué "implicaciones de rendimiento"? ¿alguien escuchó sobre la normalización y los principios de las bases de datos relacionales? ¿Cómo se actualizará/cambiará la estructura de la base de datos para más de una base de datos guardada en el dispositivo? – Ewoks

1

Eso depende realmente de sus requisitos, sin embargo, la tercera opción no parece muy práctica. Si desea hacer esto, es lo mismo que desinstalar y volver a instalar su aplicación.

Probablemente estaría más inclinado a usar la opción 2, pero depende de lo que quieras hacer en tu base de datos. p.ej. si desea estadísticas o consultas entre todos los usuarios en lugar de una persona y si hay datos comunes que se comparten entre los usuarios.

Si le preocupa el tamaño de almacenamiento, escriba un servicio que purgue los datos que pertenezcan a cualquier usuario que no haya iniciado sesión con un período de tiempo determinado.

+0

Gracias, algunas buenas sugerencias allí – Pikaling

Cuestiones relacionadas