Necesidad de almacenar LOTES de datos en el dispositivo Android, pensando en ir OODB

Aquí hay algunas observaciones, aunque sospecho que no le ayudará directamente.

Creo que las preguntas principales son: ¿Va a descubrir sus complejas relaciones a través de la lógica de ejecución de aplicaciones como eventos de generar o cambiar datos o vas a tener que simplemente volcado de datos en una tienda y luego descubre anticipar relaciones a través de consulta?

Si la lógica de su negocio llena el modelo, entonces puede crear fácilmente vistas basadas en modelos de sus distintas secciones del modelo de datos, por ejemplo, colecciones que conocen todos los coches que tienen conductores de sexo masculino / femenino. En este caso, básicamente, sus relaciones son semi-estáticas que cambian raramente (mientras que los valores de datos en el otro extremo de esas relaciones están probablemente cambiando mucho). Si este es el caso, entonces ¿por qué tratar y almacenar los datos en una tecnología de base de datos que está obligando a recalcular constantemente las relaciones (JOIN). Es sólo un desperdicio de CPU y es por eso que verá el mal desempeño como el modelo se vuelve complejo. Por lo tanto, una vez que responda a estas preguntas, será muy claro si ODB o RDB es la mejor opción.

Ahora la pregunta se convierte en, lo que se ejecutará en Android y manejar grandes datos? Aquí es donde creo que no puedo ayudar. Trabajo en Versant que tiene (db4o y Versant) ODB. Ahora db4o se ejecutará en Android, pero realmente es la elección correcta para los datos enormes … No. No a menos que tenga datos muy aislados que pueden estar en bases de datos separadas y se accede sólo de forma aislada y no me suena como es su situación. Nuestra otra base de datos, Versant es mean't para manejar enormes datos en tiempo casi real, pero sólo el cliente es 100% Java, el servidor está escrito en C, por lo que no se ejecutará en Android.

Creo que tendrá que hacer algunas investigaciones para ver quién tiene ODB que puede manejar enormes datos en Android.

Mejor, -Robert

Usted no dice mucho acerca de sus necesidades de acceso a los datos o la carga de datos realmente.

Si tienes 3M filas principales, y luego un montón de tablas de hojas más pequeñas, entonces usted puede hacer bien por el almacenamiento en caché de todas las tablas de hojas en RAM, y "unirse" a ellos a mano. Muchos sistemas tienen tablas de hojas muy pequeñas (especialmente en comparación con los datos principales), por lo que cargarlos en RAM y luego simplemente buscarlos cuando se carga la fila puede ser un gran triunfo.

Obviamente, usted no hace esto con las relaciones mayores padre-> hijo, pero si se puede eliminar la hoja se une, entonces una lectura se convierten en una sola unión entre el padre y el hijo en lugar de media docena a las tablas padre, hijo y hoja .

Incluso si esto no funciona para todas las tablas de hoja, si funciona para una gran mayoría, puede ser suficiente para llegar a la joroba.

Hablando para db4o: Ejecutamos todas nuestras pruebas de regresión en Android porque creemos que se convertirá en una plataforma muy importante para db4o.

Db4o funciona muy bien por el orden de magnitud de 3 millones de objetos.

Estamos haciendo pruebas de benchmark contra otras bases de datos en http://www.polepos.org/ y pronto lanzaremos una nueva versión del benchmark donde ejecutaremos una configuración compleja, también contra SqlLite. Portar el punto de referencia a Android también es una consideración.

Si las uniones están matando su funcionamiento y usted tiene datos muy heterogéneos, db4o podría trabajar mejor que una base de datos relacional.

Tu aplicación parece interesante. Si necesitas ayuda para evaluar db4o, solo dame un grito.

Jason: para llegar a cualquier miembro de db4o debes usar este patrón: firstname @ db4o.com ¡Mejor!