Es mejor el Join

Es mejor comparar los campos claves, los join no son estándar y x ej, en
oracle no funcionan

Tienes que pensar bien cada consulta y cada juego de indices de la base de
datos,
trata de que los indices estén en las columnas que utilizas para buscar
(buscar!! los del Where) datos frecuentemente ya que si no lo son terminarás
en búsquedas secuenciales eternas (esto es que el puntero va registro por
registro buscando el dato en esas kilométricas tablas)

La diferencia de calidad entre productos que manejan grandes bases de datos
está justamente en la velocidad de búsqueda y eso no depende de nuestra base
de datos sino de nuestra programación.

"Imac_Man" escribió en el mensaje
news:

saludos amigos.

un compañero del foro me decia que el maneja teras de informacion en
consultas y no tardan mas de 5', y yo tengo mi base de 2 gb y no logro
hacer
que los query sean rapidos, que es lo que debo hacer:

¿es mejor que use join en los select en lugar de comparar las llaves de
las
tablas?
¿hay algun problema con crear indices?
¿debo hacer un indice para cada tabla que ocupare en mis query?

gracias de antemano por su ayuda

"Imac_Man" escribió en el mensaje
news:

saludos amigos.

un compañero del foro me decia que el maneja teras de informacion en
consultas y no tardan mas de 5', y yo tengo mi base de 2 gb y no logro
hacer
que los query sean rapidos, que es lo que debo hacer:

¿es mejor que use join en los select en lugar de comparar las llaves de
las
tablas?
¿hay algun problema con crear indices?
¿debo hacer un indice para cada tabla que ocupare en mis query?

Hola:

Los JOIN son mas flexibles, y el resultado deberia ser el mismo en cuanto a
rendimiento.

Es decir, es lo mismo escribir:

SELECT Detalles.*, items.Descripcion
FROM Detalles, items
WHERE items.Codigo = Detalles.CodigoItem

que

SELECT Detalles.*, items.Descripcion
FROM Detalles INNER JOIN items
ON items.Codigo = Detalles.CodigoItem

exactamente igual. En algunos SGBD una puede ser mas rapida que la otra. Por
lo general, el JOIN describe la implementacion interna de la operacion, y
eso te podria dar algun milisegundo de ventaja en el calculo del plan de
ejecucion, pero la diferencia es despreciable.

La diferencia es que si en algun momento decides que quieres incluir TODOS
los productos (aun los que no tienen detalles), podras escribir

SELECT items.Codigo, items.Descripcion, Detalles.*
FROM items LEFT OUTER JOIN Detalles
ON items.Codigo = Detalles.CodigoItem

y eso no hay manera de escribirlo mediante la otra sintaxis. Algunos
gestores, como Oracle, utilizan una sintaxis peculiar. Pero todos los SGBD
de un tiempo a esta parte soportan plenamente los JOIN (de hecho, son la
operacion base de todas las demas).

Los indices consumen espacio y deben ser actualizados despues de cada
modificacion de una columna clave. Esto te da alguna lentitud adicional en
las operaciones de insercion/actualizacion. Pero mejoran inmensamente las
busquedas. Por lo general, es mejor tener mas indices de los necesarios que
quedarse corto.

En lo personal, hago varios indices para cada tabla, segun los diferentes
accesos que hare de ella. Si, por ejemplo quiero ver los movimientos de un
producto en un rango de fechas, hago un indice por Fecha y Codigo (y a veces
otro por Codigo y Fecha).

Si el espacio en disco no es una limitacion (impuesta, por ejemplo, por
alguna limitacion de espacio de tu SGBD), es mejor ser generoso en la
definicion de indices. Toma en cuenta que normalmente las operaciones de
insercion/actualizacion se realizan a consecuencia de la accion de un
operador (en consecuencia, el volumen de cada lote siempre es limitado, y la
sobrecarga originada en la actualizacion de los indices es pequeña),
mientras que cada operacion de selección examina grandes conjuntos de datos.
De manera que el resultado final siempre será favorable a las BBDD con los
indices necesarios.


Salud!

Hola, es muy poca la informacion q das pero podria ser

1) Diseño de la bdd
2) Indices
3) Si usas cursores

Los join o no no haran notar la diferencia, quizas tengas problemas de
compatibilidad (por ej en sql2005 no podes hacer
where tabla1.id * = tabla2.id)


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


"Imac_Man" escribió en el mensaje
news:

saludos amigos.

un compañero del foro me decia que el maneja teras de informacion en
consultas y no tardan mas de 5', y yo tengo mi base de 2 gb y no logro
hacer
que los query sean rapidos, que es lo que debo hacer:

¿es mejor que use join en los select en lugar de comparar las llaves de
las
tablas?
¿hay algun problema con crear indices?
¿debo hacer un indice para cada tabla que ocupare en mis query?

gracias de antemano por su ayuda