Consultar base de datos por cada ciclo ¿Lo hace lento ?

[informacionsys]

Buenos dias


Hola a todos..


Les comento , itero una consulta de muy pocos registros hablemos de que son 3500 registros ..

Código:

id_reg   id_suc    unidad
1          1        10 
2          1        20
3          1        30
4          2        50
5          2        35
6          2        5 
.............

, por cada id_suc(Llave foranea) diferente hago un llamado a una funcion que me retorna una arreglo de personajes .

internamente esa funcion maneja una recursividad tipo arbol , mas especificamente un arbol de grafos , como pueden saber ese proceso puede demorarse bastante tratandose de un arbol ...(Aqui es donde digo que toca la base datos la cantidad de veces segun recursividad )...

Si observamos arriba hay dos id_suc ej : 1 , 2

Al obtener por ejemplo los 700 personajes que retorno por el id_suc 1 , itero ese arreglo para realizar unas validaciones, finalmente genero un arreglo final por id_reg y los personajes finales....

si vemos la tabla de arriba, en el segundo ciclo viene el id_reg 2 y el id_suc 1 , ahi ya no tengo que ir a tocar la funcion de recursividad del id_suc 1 porque ya obtuve esa informacion en el primer ciclo .... asi sucesivamente es el proceso...

Es un proceso muy demorado y pesado.

Lo intente de otra manera , iterar el primer arreglo y almacenar en un arreglito los id_suc, despues recorrer ese arreglito y hacer el llamado a la recursividad ; almacenar todos los personajes en un arreglo final... ese arreglo final me quedo con 1400 personajes....

Iterar nuevamente el arreglo principal y dentro de este iterar el arreglo de personajes y validar el respectivo id_suc ..... de esta manera hum mejoro un poco pero no es significativo ....

A lo que quiero llegar es que ustedes me aconsejen cual es la mejor manera, en algunos casos consultar la base de datos por cada ciclo es rapido , pero en otros casos no .....

[gnzsoloyo]

Consulta una base de datos N veces para obtener X conjuntos de datos tiene varios problemas:
1) Asesina la performance de la aplicación porque estás generando N cambios de contexto.
2) Si abres una conexión para cada una, sobrecarga el spool de conexiones innecesariamente.
3) Sobrecarga el buffer de consultas en la base.
4) Consume peticiones a la base en el servidor (en los hosting tercerizados esto se penaliza).
5) Dependiendo de la sintaxis de la consulta, puede ser un serio, enorme problema de performance a nivel de BBDD.
6) muchas otras cosas que se pueden decir...
En otras palabras, es una pésima idea.

[informacionsys]

Hola

Si totalmente de acuerdo , a nivel de performance es la peor idea , pero hablemos de que es a nivel transaccional , en realidad es un proceso que se ejecuta automaticamente en cierta hora, todos los dias.

Pero lo que dices es verdad , a nivel de servidor y base es totalmente inapropiado, me preocupa bastante el performance , pero no he encontrado otra solucion ....

En el tema de peticiones a la base , uso ADODB, las consultas son bien estructuradas y son las necesarias para el proceso , y solamente abro una conexion ....

[gnzsoloyo]

Que abras una única conexión es medio irrelevante, si vas a enviar a realizar N consultas para buscar un único ID por vez, y a su vez volver a enviara a consultar algo de lo obtenido. No es eficiente, porque cada consulta, más allá de si usa una sola conexión o no, impacta en la cuenta del buffer de consultas de la base, y por ende puede terminar penalizando.
En ese sentido lo conveniente es buscar un conjunto de resultados, y si es posible obtener todos los resultados que usará la aplicación.
No puedo darte mejores consejos sin ver las queries implicadas y conocer al menos un poco de la estructura de tablas y sus relaciones, pero muy probablemente se pueda hacer un SP que retorne todo lo que necesitas, sin necesidad de hacerlo iterativamente.

[informacionsys]

hola

muchas gracias por tu interes, la idea de obtener todos los resultados necesarios con una sola llamada a la base es muy buena, pero eso no aumentaria el uso de memoria del servidor porque tendria que iterar toda la informacion para validar un solo dato...

[gnzsoloyo]

La iteracion para analizar una tabla de resultados es más rápida y con menor impacto de performance global que hacer esa misma iteracion buscando resultados en la base.
Además, la idea es precisamente optimizar la consulta a la base para que no te traiga datos inútiles, que en una iteración como la que usas, siempre ocurriría.
AL hacer las llamadas a la base iterativas, siempre existe la posibilidad de hacer consultas que no devuelven datos. En cambio en un JOIN bien diseñado, sólo volverán datos útiles.

[informacionsys]

hola

vale, por ejemplo en este script obtuve los datos globales y los procese en la aplicacion :

Editado: Código de Programación no permitido en foros de BBDD

Es valido , pero perfectamente pude haber hecho una sola consulta relacionando mi tabla usuarios y mi tabla compras .... y iterar una sola vez.

pero mirando el ejemplo , si en mi arreglo comprasUsuarioArray hay 10.000 registros y los ultimos 2.000 correspondian al primer usuario que estoy iterando , tuve primero que iterar 8.000 datos innecesarios..... en cambio si lo hago asi:

Editado: Código de Programación no permitido en foros de BBDD

Seria mucho mas rapido y no iteraria informacion innecesaria, pero la performance hacia la base seria pesima ....

Estoy un poco frustrado, pues el proceso que estoy haciendo por mas que lo mejore va a ser demorado.... y la desventaja es que no puedo usar INNER JOIN , pues como dije inicialmente es un proceso de recursividad... pero quiero dejar muy claro que opcion es mejor, siempre en todos mis proyectos he usado la segunda opcion , nunca habia notado el peso que tiene hacerlo asi, seguramente era porque fueron proyectos no robustos, pero este es totalmente distinto y eso me esta matando el performance......

la idea tambien es poder conocer sus experiencias si les ha pasado algo parecido .. y que ha sido lo mejor ..... Gracias a todos ....

[gnzsoloyo]

Bueno, vamos por parte.
Desde el punto de vista de la performance de la consulta a la base, lo relevante es la query y las condiciones de búsqueda. Eso es lo que debes postear.
El uso de recursividad para obtener datos desde programación no nos afecta, pero si las consultas, y esa parte no nos las estás mostrando.
Postea la consulta base, y qué condiciones deben tener las consultas secundarias. A partir de eso, veremos.

PD: Lo siento, pero al haber sido movido el post a PHP, este foro tiene ciertas reglas a cumplir, entre las cuales la primera es que trataremos sólo lo que tenga que ver con SQL.

[informacionsys]

hola

ok , no es un tema de base de datos, por eso lo postee en PHP , las consultas no es necesario postearlas , el problema del performance es a nivel de programacion , de php .... por eso puse los ejemplos anteriormente, para saber sus opiniones , sus ideas, que es mejor y que no, pero todo con base a php ... en base de datos nunca he tenido problemas de performance o que se me quede una consulta muchos segundos noo....

[gnzsoloyo]

Bueno, los temas de PHP los tratarás en el foro de PHP, pero a mi entender y experiencia, la performance de las consultas tiene un enorme impacto en la performance de un sistema, especialmente con planteos iterativos como los tuyos.
Ahora bien, si lo que no quieres es mostrar las queries implicadas, estás en tu derecho, pero como dije, a pesar de lo que pienses, puede ser la parte crítica del problema de performance, porque enviar N peticiones (ya lo dije antes), es ineficiente si puedes obtener todos los datos en una única llamada, y sin tantos cambios de contexto de la aplicación, así como peticiones de red y de base.
Pero, bueno, si no quieres que profundicemos el tema, lo dejo en tus manos.
Saludos.