Re: Ayuda sobre joins

Muchas gracias por la explicación.

El 22 de enero de 2010 13:37, Jaime Casanova
<jcasanov(at)systemguards(dot)com(dot)ec>escribió:

> 2010/1/22 mPerez mPerez <stylergarcia(at)gmail(dot)com>:
> > Hola a todos, quisiera que me ayuden de como es la manera mas eficiente
> de
> > sacar una consulta, si utilizando joins, subconsultas, etc.
>
> esa pregunta no tiene respuesta porque esta mal planteada y refleja
> poco conocimiento de como trabaja casi cualquier gestor de base de
> datos.
>
> en primer lugar; el SQL es un lenguaje de 4ta generación, lo que
> significa que tu solo debes preocuparte de cual es el resultado que
> quieres y es el gestor *y no tu* el que tiene la tarea de resolverlo
> de la manera mas eficiente.
>
> Debido a eso casi todo gestor, antes de ejecutar una consulta pasa por
> un proceso de optimización en el cual trata de determinar cual es la
> mejor manera de resolver la consulta que le hiciste; en el caso
> especifico de postgres normalmente ignorará el orden en que pongas las
> tablas en la clausula FROM (al menos en el caso de los INNER JOIN),
> tambien tratara de empujar las subconsultas hacia la consulta
> principal, no te permite indicar que indices debe usar o cosas como
> esa.
> La mayoría de las veces el gestor sabrá mejor que tu lo que hay que
> hacer (y antes de que digan que soy grosero, la razón por la que el
> gestor sabrá mejor que tu lo que hay que hacer es que el tiene
> estadisticas que tu no tienes, como cual es la tabla mas grande, cual
> tabla es mas probable que encuentre en memoria si alguna, cuales son
> los valores mas consultados, de que indices dispone, etc, etc, etc)
>
> En ocasiones el gestor es incapaz de determinar cual es la mejor
> manera de resolver la consulta y solo entonces vale la pena la
> intervención humana.
>
> Tratar de hacer eso antes de tiempo (es decir al armar la consulta la
> primera vez) cae en la categoria de "optimizacion adelantada" y eso mi
> amigo es la raiz de todos los males...
>
>
> Habiendo dicho todo eso, es obvio que tu consulta se resuelve con un
> join... no veo la necesidad de subconsultas por ahora, eso dejalo para
> el supuesto de que debas tratar de optimizar (y eso solo si consigues
> que el optimizador no mezcle las consultas de todos modos)
>
> --
> Atentamente,
> Jaime Casanova
> Soporte y capacitación de PostgreSQL
> Asesoría y desarrollo de sistemas
> Guayaquil - Ecuador
> Cel. +59387171157
>