No sé si es exactamente el grupo adecuado para esta pregunta.Si no es
así
pido disculpas.
Ahí va la pregunta:
¿Desde el punto de vista del rendimiento de una aplicación php/mysql
qué es
mejor una una consulta gigantesca de un tirón o pequeñas consultas
una tras
otra?.

Os pongo el ejemplo práctico.
Tengo una aplicación en la que hay usuarios.
Los datos de los usuarios están repartidos en 5 tablas relacionadas
con
claves foráneas.
Para que os hagáis una idea.
Una tabla es la de datos de usuario: nombre, fecha nacimiento, email...
Otra tabla es ciudades que está relacionada con clave foránea con la
tabla
usuarios
Otra fotos
.....Y así sucesivamente

Por ejemplo para hacer un listado global de usuarios necesito acceder a
todas esas tablas.
All principio creí que lo mejor sería hacer una consulta gigantesca
(utilizando el limit para paginar) que leyera de las 5 tablas y me
devolviera todos los datos.
La consulta para que os hagáis una idea tenía 10 líneas.
Pero ahora me estoy dando cuenta de que quizás lo mejor sea hacer las
consultas una a una.
Ej: Primero hago la consulta de los datos básicos, y luego voy una a
una con
las tablas relacionadas utilizando el id.
Esta segunda forma, desde el punto de vista de la lógica de mi
aplicación
tal y como la tengo planteada me viene muchio mejor.
Además tiene la ventaja de que si falla alguna de las consultas
secundarias
lo demás si se mostraría mientras que de la otra manera si me falla
la
consulta principal, no se muestra NADA.
¿Es muy desastroso para el rendimiento esta segunda opción?.

GRACIAS.

Las bases de datos están especializadas en devolver datos y en
cruzarlos entre ellos. Es una de las tareas básicas de las bases de
datos, asÃ*** que están optimizadas en esos términos.

AsÃ*** que, a no ser que hagas una consulta a la base de datos totalmente
ineficiente, en rendimiento de la base de datos será superior al de la
aplicación.

Espero que te haya aclarado tu duda.

El 29 Nov 2006 17:21:16 -0800 , "fReDiNi" <freduchi***gmail.com> escribió:

> No sé si es exactamente el grupo adecuado para esta pregunta.Si no es
> asÃ***
> pido disculpas.
> AhÃ*** va la pregunta:
> ¿Desde el punto de vista del rendimiento de una aplicación php/mysql
> qué es
> mejor una una consulta gigantesca de un tirón o pequeñas consultas
> una tras
> otra?.
>
> Os pongo el ejemplo práctico.
> Tengo una aplicación en la que hay usuarios.
> Los datos de los usuarios están repartidos en 5 tablas relacionadas
> con
> claves foráneas.
> Para que os hagáis una idea.
> Una tabla es la de datos de usuario: nombre, fecha nacimiento,
> email... Otra tabla es ciudades que está relacionada con clave
> foránea con la tabla
> usuarios
> Otra fotos
> ....Y asÃ*** sucesivamente
>
> Por ejemplo para hacer un listado global de usuarios necesito acceder
> a todas esas tablas.
> All principio creÃ*** que lo mejor serÃ***a hacer una consulta gigantesca
> (utilizando el limit para paginar) que leyera de las 5 tablas y me
> devolviera todos los datos.
> La consulta para que os hagáis una idea tenÃ***a 10 lÃ***neas.
> Pero ahora me estoy dando cuenta de que quizás lo mejor sea hacer las
> consultas una a una.
> Ej: Primero hago la consulta de los datos básicos, y luego voy una a
> una con
> las tablas relacionadas utilizando el id.
> Esta segunda forma, desde el punto de vista de la lógica de mi
> aplicación
> tal y como la tengo planteada me viene muchio mejor.
> Además tiene la ventaja de que si falla alguna de las consultas
> secundarias
> lo demás si se mostrarÃ***a mientras que de la otra manera si me falla
> la
> consulta principal, no se muestra NADA.
> ¿Es muy desastroso para el rendimiento esta segunda opción?.
>
> GRACIAS.
>

Las bases de datos están especializadas en devolver datos y en
cruzarlos entre ellos. Es una de las tareas básicas de las bases de
datos, asÃ*** que están optimizadas en esos términos.

AsÃ*** que, a no ser que hagas una consulta a la base de datos totalmente
ineficiente, en rendimiento de la base de datos será superior al de la
aplicación.

Espero que te haya aclarado tu duda.

El 29 Nov 2006 17:21:16 -0800 , "fReDiNi" <freduchi***gmail.com> escribió:

> No sé si es exactamente el grupo adecuado para esta pregunta.Si no es
> asÃ***
> pido disculpas.
> AhÃ*** va la pregunta:
> ¿Desde el punto de vista del rendimiento de una aplicación php/mysql
> qué es
> mejor una una consulta gigantesca de un tirón o pequeñas consultas
> una tras
> otra?.
>
> Os pongo el ejemplo práctico.
> Tengo una aplicación en la que hay usuarios.
> Los datos de los usuarios están repartidos en 5 tablas relacionadas
> con
> claves foráneas.
> Para que os hagáis una idea.
> Una tabla es la de datos de usuario: nombre, fecha nacimiento,
> email... Otra tabla es ciudades que está relacionada con clave
> foránea con la tabla
> usuarios
> Otra fotos
> ....Y asÃ*** sucesivamente
>
> Por ejemplo para hacer un listado global de usuarios necesito acceder
> a todas esas tablas.
> All principio creÃ*** que lo mejor serÃ***a hacer una consulta gigantesca
> (utilizando el limit para paginar) que leyera de las 5 tablas y me
> devolviera todos los datos.
> La consulta para que os hagáis una idea tenÃ***a 10 lÃ***neas.
> Pero ahora me estoy dando cuenta de que quizás lo mejor sea hacer las
> consultas una a una.
> Ej: Primero hago la consulta de los datos básicos, y luego voy una a
> una con
> las tablas relacionadas utilizando el id.
> Esta segunda forma, desde el punto de vista de la lógica de mi
> aplicación
> tal y como la tengo planteada me viene muchio mejor.
> Además tiene la ventaja de que si falla alguna de las consultas
> secundarias
> lo demás si se mostrarÃ***a mientras que de la otra manera si me falla
> la
> consulta principal, no se muestra NADA.
> ¿Es muy desastroso para el rendimiento esta segunda opción?.
>
> GRACIAS.
>

Las bases de datos están especializadas en devolver datos y en
cruzarlos entre ellos. Es una de las tareas básicas de las bases de
datos, asÃ*** que están optimizadas en esos términos.

AsÃ*** que, a no ser que hagas una consulta a la base de datos totalmente
ineficiente, en rendimiento de la base de datos será superior al de la
aplicación.

Espero que te haya aclarado tu duda.

El 29 Nov 2006 17:21:16 -0800 , "fReDiNi" <freduchi***gmail.com> escribió:

> No sé si es exactamente el grupo adecuado para esta pregunta.Si no es
> asÃ***
> pido disculpas.
> AhÃ*** va la pregunta:
> ¿Desde el punto de vista del rendimiento de una aplicación php/mysql
> qué es
> mejor una una consulta gigantesca de un tirón o pequeñas consultas
> una tras
> otra?.
>
> Os pongo el ejemplo práctico.
> Tengo una aplicación en la que hay usuarios.
> Los datos de los usuarios están repartidos en 5 tablas relacionadas
> con
> claves foráneas.
> Para que os hagáis una idea.
> Una tabla es la de datos de usuario: nombre, fecha nacimiento,
> email... Otra tabla es ciudades que está relacionada con clave
> foránea con la tabla
> usuarios
> Otra fotos
> ....Y asÃ*** sucesivamente
>
> Por ejemplo para hacer un listado global de usuarios necesito acceder
> a todas esas tablas.
> All principio creÃ*** que lo mejor serÃ***a hacer una consulta gigantesca
> (utilizando el limit para paginar) que leyera de las 5 tablas y me
> devolviera todos los datos.
> La consulta para que os hagáis una idea tenÃ***a 10 lÃ***neas.
> Pero ahora me estoy dando cuenta de que quizás lo mejor sea hacer las
> consultas una a una.
> Ej: Primero hago la consulta de los datos básicos, y luego voy una a
> una con
> las tablas relacionadas utilizando el id.
> Esta segunda forma, desde el punto de vista de la lógica de mi
> aplicación
> tal y como la tengo planteada me viene muchio mejor.
> Además tiene la ventaja de que si falla alguna de las consultas
> secundarias
> lo demás si se mostrarÃ***a mientras que de la otra manera si me falla
> la
> consulta principal, no se muestra NADA.
> ¿Es muy desastroso para el rendimiento esta segunda opción?.
>
> GRACIAS.
>

Las bases de datos están especializadas en devolver datos y en
cruzarlos entre ellos. Es una de las tareas básicas de las bases de
datos, asÃ*** que están optimizadas en esos términos.

AsÃ*** que, a no ser que hagas una consulta a la base de datos totalmente
ineficiente, en rendimiento de la base de datos será superior al de la
aplicación.

Espero que te haya aclarado tu duda.

El 29 Nov 2006 17:21:16 -0800 , "fReDiNi" <freduchi***gmail.com> escribió:

> No sé si es exactamente el grupo adecuado para esta pregunta.Si no es
> asÃ***
> pido disculpas.
> AhÃ*** va la pregunta:
> ¿Desde el punto de vista del rendimiento de una aplicación php/mysql
> qué es
> mejor una una consulta gigantesca de un tirón o pequeñas consultas
> una tras
> otra?.
>
> Os pongo el ejemplo práctico.
> Tengo una aplicación en la que hay usuarios.
> Los datos de los usuarios están repartidos en 5 tablas relacionadas
> con
> claves foráneas.
> Para que os hagáis una idea.
> Una tabla es la de datos de usuario: nombre, fecha nacimiento,
> email... Otra tabla es ciudades que está relacionada con clave
> foránea con la tabla
> usuarios
> Otra fotos
> ....Y asÃ*** sucesivamente
>
> Por ejemplo para hacer un listado global de usuarios necesito acceder
> a todas esas tablas.
> All principio creÃ*** que lo mejor serÃ***a hacer una consulta gigantesca
> (utilizando el limit para paginar) que leyera de las 5 tablas y me
> devolviera todos los datos.
> La consulta para que os hagáis una idea tenÃ***a 10 lÃ***neas.
> Pero ahora me estoy dando cuenta de que quizás lo mejor sea hacer las
> consultas una a una.
> Ej: Primero hago la consulta de los datos básicos, y luego voy una a
> una con
> las tablas relacionadas utilizando el id.
> Esta segunda forma, desde el punto de vista de la lógica de mi
> aplicación
> tal y como la tengo planteada me viene muchio mejor.
> Además tiene la ventaja de que si falla alguna de las consultas
> secundarias
> lo demás si se mostrarÃ***a mientras que de la otra manera si me falla
> la
> consulta principal, no se muestra NADA.
> ¿Es muy desastroso para el rendimiento esta segunda opción?.
>
> GRACIAS.
>

Las bases de datos están especializadas en devolver datos y en
cruzarlos entre ellos. Es una de las tareas básicas de las bases de
datos, asÃ*** que están optimizadas en esos términos.

AsÃ*** que, a no ser que hagas una consulta a la base de datos totalmente
ineficiente, en rendimiento de la base de datos será superior al de la
aplicación.

Espero que te haya aclarado tu duda.

El 29 Nov 2006 17:21:16 -0800 , "fReDiNi" <freduchi***gmail.com> escribió:

> No sé si es exactamente el grupo adecuado para esta pregunta.Si no es
> asÃ***
> pido disculpas.
> AhÃ*** va la pregunta:
> ¿Desde el punto de vista del rendimiento de una aplicación php/mysql
> qué es
> mejor una una consulta gigantesca de un tirón o pequeñas consultas
> una tras
> otra?.
>
> Os pongo el ejemplo práctico.
> Tengo una aplicación en la que hay usuarios.
> Los datos de los usuarios están repartidos en 5 tablas relacionadas
> con
> claves foráneas.
> Para que os hagáis una idea.
> Una tabla es la de datos de usuario: nombre, fecha nacimiento,
> email... Otra tabla es ciudades que está relacionada con clave
> foránea con la tabla
> usuarios
> Otra fotos
> ....Y asÃ*** sucesivamente
>
> Por ejemplo para hacer un listado global de usuarios necesito acceder
> a todas esas tablas.
> All principio creÃ*** que lo mejor serÃ***a hacer una consulta gigantesca
> (utilizando el limit para paginar) que leyera de las 5 tablas y me
> devolviera todos los datos.
> La consulta para que os hagáis una idea tenÃ***a 10 lÃ***neas.
> Pero ahora me estoy dando cuenta de que quizás lo mejor sea hacer las
> consultas una a una.
> Ej: Primero hago la consulta de los datos básicos, y luego voy una a
> una con
> las tablas relacionadas utilizando el id.
> Esta segunda forma, desde el punto de vista de la lógica de mi
> aplicación
> tal y como la tengo planteada me viene muchio mejor.
> Además tiene la ventaja de que si falla alguna de las consultas
> secundarias
> lo demás si se mostrarÃ***a mientras que de la otra manera si me falla
> la
> consulta principal, no se muestra NADA.
> ¿Es muy desastroso para el rendimiento esta segunda opción?.
>
> GRACIAS.
>

Las bases de datos están especializadas en devolver datos y en
cruzarlos entre ellos. Es una de las tareas básicas de las bases de
datos, asÃ*** que están optimizadas en esos términos.

AsÃ*** que, a no ser que hagas una consulta a la base de datos totalmente
ineficiente, en rendimiento de la base de datos será superior al de la
aplicación.

Espero que te haya aclarado tu duda.

El 29 Nov 2006 17:21:16 -0800 , "fReDiNi" <freduchi***gmail.com> escribió:

> No sé si es exactamente el grupo adecuado para esta pregunta.Si no es
> asÃ***
> pido disculpas.
> AhÃ*** va la pregunta:
> ¿Desde el punto de vista del rendimiento de una aplicación php/mysql
> qué es
> mejor una una consulta gigantesca de un tirón o pequeñas consultas
> una tras
> otra?.
>
> Os pongo el ejemplo práctico.
> Tengo una aplicación en la que hay usuarios.
> Los datos de los usuarios están repartidos en 5 tablas relacionadas
> con
> claves foráneas.
> Para que os hagáis una idea.
> Una tabla es la de datos de usuario: nombre, fecha nacimiento,
> email... Otra tabla es ciudades que está relacionada con clave
> foránea con la tabla
> usuarios
> Otra fotos
> ....Y asÃ*** sucesivamente
>
> Por ejemplo para hacer un listado global de usuarios necesito acceder
> a todas esas tablas.
> All principio creÃ*** que lo mejor serÃ***a hacer una consulta gigantesca
> (utilizando el limit para paginar) que leyera de las 5 tablas y me
> devolviera todos los datos.
> La consulta para que os hagáis una idea tenÃ***a 10 lÃ***neas.
> Pero ahora me estoy dando cuenta de que quizás lo mejor sea hacer las
> consultas una a una.
> Ej: Primero hago la consulta de los datos básicos, y luego voy una a
> una con
> las tablas relacionadas utilizando el id.
> Esta segunda forma, desde el punto de vista de la lógica de mi
> aplicación
> tal y como la tengo planteada me viene muchio mejor.
> Además tiene la ventaja de que si falla alguna de las consultas
> secundarias
> lo demás si se mostrarÃ***a mientras que de la otra manera si me falla
> la
> consulta principal, no se muestra NADA.
> ¿Es muy desastroso para el rendimiento esta segunda opción?.
>
> GRACIAS.
>

El Thu, 30 Nov 2006 04:26:48 +0100 , Juan José del RÃ***o
<juanjose***simpleoption.com> escribió:

> Las bases de datos están especializadas en devolver datos y en
> cruzarlos entre ellos. Es una de las tareas básicas de las bases de
> datos, asÃ*** que están optimizadas en esos términos.
>
> AsÃ*** que, a no ser que hagas una consulta a la base de datos totalmente
> ineficiente, en rendimiento de la base de datos será superior al de la
> aplicación.
>
> Espero que te haya aclarado tu duda.
>

Aún asÃ***, estoy hablando estrictamente en términos de rendimiento. En
caso de que no tengas problemas de rendimiento actualmente, pues te
recomiendo la opción que haga que tu aplicación sea más mantenible y
legible.

Es más, también puedes optar por una solución mixta. De forma que en
vez de hacer una petición gigante, puedas hacer varias peticiones más
pequeñas.

En el caso de que la lista de usuarios sea algo que necesites a menudo,
pues entonces no has diseñado correctamente la base de datos. También
puede ser que necesites rediseñar la base de datos para que se adapte
mejor a lo que pretendes, pero eso es una locura si la aplicación ya
está en uso, o en una fase de desarrollo avanzada.

Recuerda siempre que el primer objetivo es la legibilidad del código,
que es lo que más resulta rentable a largo plazo, a la hora del
mantenimiento y la ampliación del software.

Parafraseando a una importante figura en el campo de la informática:
"El software está hecho para ser leÃ***do y comprendido, y en algunos
casos ejecutado."

Saludos,
Juan José

El Thu, 30 Nov 2006 04:26:48 +0100 , Juan José del RÃ***o
<juanjose***simpleoption.com> escribió:

> Las bases de datos están especializadas en devolver datos y en
> cruzarlos entre ellos. Es una de las tareas básicas de las bases de
> datos, asÃ*** que están optimizadas en esos términos.
>
> AsÃ*** que, a no ser que hagas una consulta a la base de datos totalmente
> ineficiente, en rendimiento de la base de datos será superior al de la
> aplicación.
>
> Espero que te haya aclarado tu duda.
>

Aún asÃ***, estoy hablando estrictamente en términos de rendimiento. En
caso de que no tengas problemas de rendimiento actualmente, pues te
recomiendo la opción que haga que tu aplicación sea más mantenible y
legible.

Es más, también puedes optar por una solución mixta. De forma que en
vez de hacer una petición gigante, puedas hacer varias peticiones más
pequeñas.

En el caso de que la lista de usuarios sea algo que necesites a menudo,
pues entonces no has diseñado correctamente la base de datos. También
puede ser que necesites rediseñar la base de datos para que se adapte
mejor a lo que pretendes, pero eso es una locura si la aplicación ya
está en uso, o en una fase de desarrollo avanzada.

Recuerda siempre que el primer objetivo es la legibilidad del código,
que es lo que más resulta rentable a largo plazo, a la hora del
mantenimiento y la ampliación del software.

Parafraseando a una importante figura en el campo de la informática:
"El software está hecho para ser leÃ***do y comprendido, y en algunos
casos ejecutado."

Saludos,
Juan José

El Thu, 30 Nov 2006 04:26:48 +0100 , Juan José del RÃ***o
<juanjose***simpleoption.com> escribió:

> Las bases de datos están especializadas en devolver datos y en
> cruzarlos entre ellos. Es una de las tareas básicas de las bases de
> datos, asÃ*** que están optimizadas en esos términos.
>
> AsÃ*** que, a no ser que hagas una consulta a la base de datos totalmente
> ineficiente, en rendimiento de la base de datos será superior al de la
> aplicación.
>
> Espero que te haya aclarado tu duda.
>

Aún asÃ***, estoy hablando estrictamente en términos de rendimiento. En
caso de que no tengas problemas de rendimiento actualmente, pues te
recomiendo la opción que haga que tu aplicación sea más mantenible y
legible.

Es más, también puedes optar por una solución mixta. De forma que en
vez de hacer una petición gigante, puedas hacer varias peticiones más
pequeñas.

En el caso de que la lista de usuarios sea algo que necesites a menudo,
pues entonces no has diseñado correctamente la base de datos. También
puede ser que necesites rediseñar la base de datos para que se adapte
mejor a lo que pretendes, pero eso es una locura si la aplicación ya
está en uso, o en una fase de desarrollo avanzada.

Recuerda siempre que el primer objetivo es la legibilidad del código,
que es lo que más resulta rentable a largo plazo, a la hora del
mantenimiento y la ampliación del software.

Parafraseando a una importante figura en el campo de la informática:
"El software está hecho para ser leÃ***do y comprendido, y en algunos
casos ejecutado."

Saludos,
Juan José