¿Cómo lleva Android los joins en las bases de datos?

[partisano]

Hola a todos, estoy barajando hacer una aplicación para Android como mi proyecto fin de carrera y me gustaría saber algo: ¿qué tal se porta Android con los joins en las bases de datos?

Es decir, Android trabaja con bases de datos SQLite, ¿no? Sé que SQLite permite realizar joins entre varias tablas pero, ¿y en Android? ¿Puede con los joins? Más sencillo todavía: ¿todos los terminales Android (de gama media, los de baja intuyo que no podrán) pueden realizar un join entre 3 o 4 tablas? ¿O se quedan sin recursos tardando la vida en mostrar el resultado o, incluso, dan FC?

Por favor, a ver si alguien me ilumina. Muchas gracias. Saludos!

[manelizzard]

Uop! Interesante pregunta!

Atendiendo que es un PFC, supongo que los volúmenes de datos serán increíblemente grandes (tablas del orden de 10.000 filas, no?). Evidentemente, si son 4 tablas de 3 filas no tendrás ningún problema :P

Como dices, los terminales de gama alta y media funcionarán sin mucha demora, aunque los de baja tal vez tarden algo más en procesar. No obstante, si la consulta a la base de datos (es decir, los joins), los haces dentro de un thread aparte que no sea el UI Thread (rollo AsyncTask, etc.) y muestras una barra de progreso o algo similar (loading...), nunca te dará un FC.

Además, veo muy interesante hacer un estudio de terminales en cuanto a la velocidad de procesamiento de grandes consultas SQLite! Si lo llevas a cabo, ya nos dejarás ver los resultados de la investigación :D

Suerte!

[Celtium]

....

Además, veo muy interesante hacer un estudio de terminales en cuanto a la velocidad de procesamiento de grandes consultas SQLite! Si lo llevas a cabo, ya nos dejarás ver los resultados de la investigación :D

Suerte!

buena propuesta. Yo sopongo que para consultas en db pequeñas no debía demorar nada independientemente del terminal. Si realmente necesitas una gran db seria mejor no usar la sqlite...

[partisano]

Gracias a ambos por las respuestas.

@manelizzard el volumen de datos es variable, no tengo por qué tener exceso de datos... lo que sí tengo es muchas tablas: 17! Y eso que no están en FNBC jajaja. El caso es que tendría que hacer joins de 3 e incluso 4 tablas y he ahí mi duda. Porque de no ser factible para teléfonos de gama baja (o media por los pelos como el Samsung Galaxy S, que el profesor que me llevaría el proyecto tiene ese móvil jaja) entonces ya no podría embarcarme en ese proyecto ya que sería un fracaso absoluto jaja.

@Celtium qué es eso de que sería mejor no usar la BBDD en SQLite? Tenía entendido que la BBDD para una aplicación Android ha de ir, sí o sí, en SQLite: ¿estoy equivocado entonces? Si lo estoy, ¿qué otros motores de BBDD soporta Android? Y si no lo estoy pues entonces no tiene sentido lo de no usar SQLite porque si no ya me dirás cómo logro la persistencia jaja.

[superroko2]

Gracias a ambos por las respuestas.

@manelizzard el volumen de datos es variable, no tengo por qué tener exceso de datos... lo que sí tengo es muchas tablas: 17! Y eso que no están en FNBC jajaja. El caso es que tendría que hacer joins de 3 e incluso 4 tablas y he ahí mi duda. Porque de no ser factible para teléfonos de gama baja (o media por los pelos como el Samsung Galaxy S, que el profesor que me llevaría el proyecto tiene ese móvil jaja) entonces ya no podría embarcarme en ese proyecto ya que sería un fracaso absoluto jaja.

@Celtium qué es eso de que sería mejor no usar la BBDD en SQLite? Tenía entendido que la BBDD para una aplicación Android ha de ir, sí o sí, en SQLite: ¿estoy equivocado entonces? Si lo estoy, ¿qué otros motores de BBDD soporta Android? Y si no lo estoy pues entonces no tiene sentido lo de no usar SQLite porque si no ya me dirás cómo logro la persistencia jaja.


Tener una BD fuera de la aplicación por ejemplo en un servidor MySQL externo no es una buena alternativa, no?

PD: Por preguntar que no quede.

[partisano]

Tener una BD fuera de la aplicación por ejemplo en un servidor MySQL externo no es una buena alternativa, no?

PD: Por preguntar que no quede.

No, no lo es. La idea del PFC es poder tener disponible los datos en local y sincronizar cuando quieras por red, pero las nuevas tuplas se introducirán en local. Así han descrito el PFC en la facultad :(

Gracias

Enviado desde mi Samsung Galaxy S II

[Celtium]

Hola,

La base sqlite se supone que es para trabajar cómodamente con muchos datos en una aplicación en comparación con el uso de arrays, shares, etc. Pero claro hay que tener en cuenta que tiene inconvenientes entre ellos la potencia de la db y la sincronización de los datos entre usuarios.

Las consultas son muy complejas? intervienen varias tablas con muchas registros? hacer un inner join full entre 4 tablas de 5000 registros lleva tiempo y consume recursos, ademas de batería. Si se hace muy a menudo (si las hace) puede afectar a la experiencia del usuario y no solo en los retardos que los puedes disimular haciéndolos antes de que haya que mostrar los datos, sino también en la batería, recalentamiento, etc. (siendo un uso intensivo)

Si se esos datos tienen que poder ser accesibles por muchos usuarios en tiempo real pues olvídate de tener toda la base en local, lo mas probable es que tengas perdidas de datos o incongruencias.

Si tu proyecto es hacerlo en local no creo que tengas problemas, pero controla los tiempos de respuesta y afina el código para que no se note.

Lo primero que se hace es crearte un servidor en "casa" mysql (tipo XAMMP) y hacer conexiones directas contra la base desde la app, después te das cuenta que va lento. En cada consulta desde que se abre el socket via gsm hasta que se cierra puede tardar como 10 segundos... una burrada, saturas base con pocos usuarios. Entonces se te ocurre hacer un "servidor web" en donde las consultas están en, por ejemplo, php. Este código php genera una pag web con solo los datos que resultan de la consulta, así ganas en rapidez, el servidor libera esa conexión en milisegundos y podrá hacer muchas mas consultas en el mismo segundo. Después de hacer todo, piensas, bueno tener el servidor en "casa" siempre encendido es caro ademas de que si te falla o se rompe algo... te saldrá un pico repararlo y se quedara sin servicio la app un tiempo. Entoces migras todo lo hecho a un alojamiento web con Mysql que te vale 28 € al año....

Si tienes pasta y la app tiene muchos, pero que muchos clientes, pasas del ultimo paso anterior y te contratas un servidor virtual en Internet. Alli configuras la base y te haces un servicio web de verdad con las ventajas que tiene.

Al ser un proyecto de final de carrera no creo que te exijan hilar muy fino, si ya en si se basa en tener disponible los datos en local y sincronizar cuando quieras por red la propia base estará diseñada para no saturar el móvil.

Como siempre, es mi opinión.

[partisano]

@celtium gracias por tu respuesta. Sí, las consultas pueden tener muchas tuplas... imagínate: supermercados, precios y productos... vamos, un porrón! jajaja. Los datos están accesibles únicamente en el dispositivo, no se comparten entre usuarios.

Pero tengo la oportunidad de elegir entre rehacer la aplicación para Android que hizo otro alumno (está hecha una mierda: sólo tiene 2 tablas y para eso ni siquiera están relacionadas!!!!! y tiene redundancia por un tubo) o hacer una aplicación web con el servidor para importar y exportar datos compatibles con este formato (el de la BBDD que está tan mal hecha). Eso sí, mi BBDD estaría en MySQL y mucho mejor hecha (de hecho ya tengo hecho el modelo de datos): la perrada es que como he hecho una ingeniería técnica no tengo conocimientos de la tecnología que tengo que utilizar (Spring MVC, Maven, Tapestry o JSF, Hibernate, etc).... y de programación Android tampoco jajaja. Y lo peor es la lógica de negocio para pasar de un formato al otro y que se pierdan los menos datos posibles.

Así que estoy en ese complicado punto :(. Tendría que aprender o programación en Android o todo lo que he dicho anteriormente y no sé en qué será menos pronunciada la curva de aprendizaje.

Edito: ah! Y nada de PHP: me han dicho que o J2EE o .NET

[manelizzard]

.NET? Ay dios mío... pobrete :P

Si tienes que desarrollar la parte servidora, yo tiraría por J2EE, ya que así obtendrás soltura en programación Java (que es la base de la programación Android).

Ahora tendrás que pensar "a lo grande", como tu dices, tener un modelo de datos en el servidor que ofrezca datos, y el consecuente modelo en la aplicación Android para mantener una coherencia.

Lo bueno de esto, es que el 90% de las aplicaciones son básicamente así: servicios REST ofreciendo datos, cliente móvil mostrando/editando datos. Con esto, igual puedes presentarte a algún puesto de trabajo decente como Android developer ^^

Ánimo chico!

[Celtium]

Cuando se crece y la app ya necesita el servicio web si puedes plantearte hacerlo bien. yo prefiero hacerlo en J2EE antes que en .net por que se más java nada más. Al final se escoge el lenguaje que se recomienda por estar mejor dotado para hacer algo y por que uno sabe más del.

También te digo, la opción php es la mas barata para hacer algo real tanto en costes de infraestructura como en tiempo de desarrollo. Da bastante buen servicio de servidor, en cuanto a conexiones simultaneas y es extremadamente fácil hacerlo. Yo soy de los que opino que antes de invertir muchos recursos en hacer algo hay que ver si funciona y retorna algún ingreso.

Suerte con el proyecto. ;)