sql: rendimiento de consultas

[joja_2]

Hola

me gustaría saber qué consulta es más eficiente, una con un inner join o la misma con left o right join?
y las subconsultas como andan de rendimiento?

es que tengo una base de datos con muchisimos registros y queremos optimizar el rendimiento en búsquedas y muestras de datos en tablas en las paginas web.

gracias

[RootK]

Hola...

qué consulta es más eficiente, una con un inner join o la misma con left o right join?

Creo que cada una hace cosas diferentes y todo depende de la info que desees obtener porque no es lo mismo hacer un inner join que un left or right join.

y las subconsultas como andan de rendimiento?

Tambien depende del tamaño de tu subquery.., pero te puedes apoyar de un inner join.., a menos que sea necesaria una subquery puede servir de mucho..

Como verás.., el costo de tu query va a depende del tamaño de registros que se regresen, filtros, sorting, anidamientos, si usas índices. .si el SGBD lo soporta te puedes apoyar de SP, functions, etc.

Salu2

[Mithrandir]

Escribe las 3 consultas en el Query Analyzer, entonces genera el Plan de Ejecucion.

La que tenga el valor mas bajo en "Estimated Tree Cost" es la mas eficiente. Aunque como ya te dijo RootK, cada una tiene su aplicacion especifica, por lo que no son intercambiables

[Vice]

Creo que esto tendría bastante que hablar, pues cualquier consulta se puede montar de maneras diferentes.
Lo mejor es usar el analizador y ver cual es la que mejor rendimiento te da.
Si bien es cierto un join es habitualmente mejor que una subquery, a veces (sólo a veces) es mejor hacer la subquery, todo depende en cada consulta.

Desde luego lo que no tiene sentido es comparar el rendimiento de un left/right join con un inner join, pues devuelven resultados diferentes y tienen aplicaciones diferentes. Con la pregunta, tal como la pones, desde luego un left/rigth join van a tardar más que un inner join, pero también van a dar un resultado diferente con un número de filas mayor o igual que el del inner join.
Un saludo.