excelente respuesta jaimes, esto me aclara muchas cosas. El 23 de enero de 2010 14:07, Jaime Casanova <[email protected]>escribió:
> 2010/1/22 mPerez mPerez <[email protected]>: > > 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 > -- > TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net >
