¿INNER JOIN o Comparaciones en el Where?

[wilwas]

Hola Chicos,

Vereis tengo un pequeño problema de rendimiento con una consulta, el caso es que en esta consulta intervienen 7 tablas y los consiguientes INNER JOIN,
la consulta tarda y no se como sulucionarlo ya que necesito todos los datos de todas esas tablas.

Mi pregunta es que diferencia habria entre hacerlo con:
- INNER JOIN TABLA1 ON TABLA1.ID 0 TABLA2.ID
o
- WHERE TABLA1.ID = TABLA2.ID

¿Que forma es mejor, mas rapido o que ventajas tiene?


Muchas Gracias

[wilwas]

Una cosa mas realacionada con el tema.

Si quiero poner una condicion, donde es mejor ponerla, en el inner join o en el where?

Muchas Gracias!!

[arrebatos]

Suelo hacer consultas que deben funcionar en SQL server, Oracle y DB2. Por esa razón suelo usar la cláusula WHERE. Sin embargo se supone que es más eficaz la cláusula FROM xxx INNER JOIN xxxx, pues para eso está concebida.
Sin tienes problemas de rendimiento, échale un vistazo a los índices de esas tablas y corrígelos si lo crees necesario (usa el analizador de consultas, opción analizar para ver dónde pierdes más).
Además puedes crear una vista para esa consulta (o incluso un sp) que seguro será más rápido.

Un saludo

[Developer9]

Alguien sabe algo mas? técnicamente hablando

[claray]

Hola, me permito comentar mi experiencia propia, que aunque no soy experto (no creo en ellos) tengo un tiempo trabajando con B/D.

De acuerdo a lo que he visto, efectecvimanete los JOIN, bien planteados funcionan levemente mas rapido que las consultas armadas con el WHERE (sin JOIN).

Lo que realmente es MUY relevante es la existencia de indices que permitan realizar las busquedas y enlaces de registros de manera rapida al motor.

A este punto es importante recalcar que el orden es que son presentados los elementos parte de una clave SI es relevante para el uso de un indice, me explico:

Si la tabla tiene un indice compuesto por los campos c1,c2 y c3 y se realiza un consulta, se debe procurar que los campos sean presentados en ese orden , es decir, la siguiente consulta usara el indice:

Select * from tabla where c1='a' and c2='b' and c3='c'

pero, esta otra no:

Select * from tabla where c2='b' and c3='c' and c1='a'

ya que los campos no estan ordenados en la condicion.

De la misma forma, si se presenta una condicion usando solo parte de los campos del indice, este sera usado, es decir, la siguiente consulta usara el indice:

Select * from tabla where c1='a' and c2='b'

En el caso de los JOIN, hay que asegurarse que las tablas que se van enlazando tengan indices por los campos de enlace.

saludos y suerte

[Myakire]

Siempre he sido partidario de buscar este tipo de cosas en fuentes "más formales", como libros, por ejemplo, y no por "oidas", pero si en algo puede servir mi aporte ...

Bueno, según tengo entendido hacer relaciones con WHERE no esta aprovechando los índices ni relaciones de las tablas, sino que forma un simple producto cartesiano (a cada registro de A lo juntamos con todos los de B) y luego, después de eso, se hace un filtro con la condición. Eso a todas luces es pésima idea para muchas tablas o tablas muy grandes. Ahí es dónde el INNER o el OUTER ponen la diferencia dado que filtran desde el momento de las relaciones por medio de los índices... ¿cómo? ... aahh, pues ahí si me disculparán ya que nunca les mentiría con conocimiento de causa, lo desconozco.

Sobre el de poner condiciones en el WHERE o en el INNER, pues son cosas distintas. La condición del ON que va con el INNER es para proporcionar una relación entre las dos tablas, no para filtrar, para eso esta el WHERE, así como el HAVING para condiciones a nivel de grupos.

Mis 2 centavos

[Mithrandir]

Adicionalmente. Alguna vez hice la prueba y las series de tablas separadas por comas el optimizador las tradujo internamente a JOINs, de manera que daba exactamente lo mismo una cosa que otra.

Desconozco si eso aplique en todas las posibilidades que puedan darse, pero además de ser una mala práctica, obtienes un super-mega-where con todo revuelto que en 6 meses que regreses no entenderás para que es cada parte.