Consulta en MySQL

[Jeronimo]

¡Listo, Yván!
Al registrarme no me dijo nada acerca de tus 500 mb, supongo que será algo automático. Si no te los dieron, por favor decime qué debo hacer para que lo hagan.
Aquí está el enlace al archivo: https://www.dropbox.com/s/8e3tmp2oa7chwqe/New%20Project%2020121120%200050.sql
Muchas gracias.

Jerónimo

[seba123neo]

bueno la pude montar sin problemas.

lo que hace lento la consulta es el LEFT JOIN de la tercera tabla, entonces procedi a poner como clave primaria en la tabla "preciosarticulos" , los campos articulo y listaprecios (ya que el mismo articulo puede estar varias veces en la misma tabla para otra lista de precios) y ahora la consulta tarda 0.0029 segundos.

[Jeronimo]

seba123neo: ¡INMENSO! ¡Increíble!
Yván y seba123neo: no tengo palabras para agradecerles, porque todo queda chico.
Perdón por la insistencia, pero soy nuevo en esto de la participación en foros (de hecho, solo participo en uno aparte de este). Me llama mucho la atención, me parece genial y me provoca un eterno agradecimiento ver cómo hay gente que comparte conocimientos y se toma el tiempo (hoy en día vale mucho) y la molestia de leer problemas de gente desconocida solo por el hecho de ayudarla.
Señores: mi más profunda admiración por esto y por su nivel de conocimiento.
Volviendo a lo que estrictamente tiene que ver con el hilo, ¿por qué se reduce tanto el tiempo de consulta al poner las claves principales?
Saludos.

Jerónimo

[seba123neo]

porque lo encuentra o indexa mas rapido, sin eso me imagino que internamente debe buscar por cada relacion en toda la tabla y eso hace que tarde mas, es como los indices de un libro, si tengo un libro y quiero llegar a la pagina 534 tengo que abrirlo y empezar a buscar la pagina, capas que tardo 5 segundos en encontrarla, pero si le pongo un indice o un papelito en esa pagina, lo encuentro al instante, aca una explicacion que me gusto de internet que lo explica sencillo y bien:

y no confundir claves principales (PK), con los indices.

Toda llave primaria es un indice, un indice no siempre es una llave primaria

los indices son bueno como (su nombre lo indica) como lo indices de un libro, estos te ayudan a poder realizar busquedas mas rapidas sobre algunos campos especificos, basicamente sirven para agilizar las consultas, pueden existir indices simples (solo 1 campo) o compuestos (2 o mas campos).

En un indice puedes tener valores repetidos sin problemas, lo ideal es que los campos que son indexados sean con valores muy variables para evitar que se pierda el objetivo de un indice (por ejemplo si indexas un nombre seria alfabeticamente y cuando buscas algo con G se iria a la seccion correspondiente ignorando todos los que estan delante; pero si indexas un campo SI/NO pues habria muchisimas coincidencias y terminaria variendo casi el 50% de la tabla)

las PK (primary key) son los identificadores del registro y debe ser UNICO, estas PK pueden ser sencillas o compuestas al igual que los indices. Los PK son una clase particular de indices, ya que este es el indice principal por lo general los PK son numericos pero hay sus excepciones dependiendo del desarrollo.

saludos.

[Jeronimo]

¡Excelente!
Un último pedido (por ahora jeje), doble en realidad: por un lado, ¿me podés decir un buen lugar donde pueda aprender más sobre este tipo de cosas? Estoy seguro de que mi base de datos tiene un montón de errores de diseño y quiero tratar de optimizarla.
Por otro lado, ¿me ayudás con otra cuestión similar a esta? Tengo ahora que relacionar dos tablas nomás y la consulta tarda 4 segundos. Puse las claves principales (ahora entiendo que deben ser índices) pero no mejora nada. Ahora debo salir. En un rato pongo el archivo como hice con el anterior por si podés echarle una mirada. Pensé que con tu ejemplo anterior podía solucionar también esto, pero no fue así.
Muchas gracias.

Jerónimo

[YAcosta]

Hola Jeronimo acabo de prender mi PC y ya veo el mensaje de espacio aumentado, gracias. Ahora debe ser que tu también tengas aumentado seria que veas en las propiedades, también debes cumplir unos pasos que alli te indica para que aumente, luego recuerda que debes dar tu enlace (no el mio) a otras personas con el mismo problema para que consigas aumentar de 500 en 500.

Yendo a tu problema resuelto, la intervención y explicación de Sebas es oportuna, efectiva y clara, no tengo nada mas que aumentar sobre este tema, en el segundo problema que tienes no has publicado el enlace al archivo.

Sobre manuales de SQL, la verdad no tengo una fuente fija y completa, cuando yo empece en realidad lei de varios sitios empezando por aquellos que los veia mas nutrido y con mas ejemplos los cuales encontré googleando. Luego con el uso me bastaba con búsquedas en la red. Y al final para preguntas especificas yo en foros, aunque de SQL no pregunte mucho en comparación a VB6.

Aqui te paso un apartado de mi proveedor de host que te puede ser pertinente, dale una leidita, por lo demas pregunta por aqui que te estaremos dando una mano (o dos)

http://blog.infranetworking.com/optimizando-consultas-lentas-sql/

[Jeronimo]

Muchas gracias, Yván.
En cuanto a Dropbox, solo lo instalé y luego vi por ahí que tenía una capacidad de 2,5 gb, de manera que debo haber recibido los 500 mb por tu referencia. ¡Gracias!
Con relación al archivo, aquí va el enlace: https://www.dropbox.com/s/u2u3a18bi1wu8hc/New%20Project%2020121120%201258.sql
En la tabla stockarticulos hay algunos campos que ya no se usan (aunque todavía no quité el código que los completa).
El problema es que la siguiente consulta tarda 4 segundos, cuando, en teoría, debiera ser instantánea:

Código: [Seleccionar]

SELECT a.descripcion, a.codigo, a.stockminimo, sa.cantidad
FROM articulos a LEFT JOIN stockarticulos sa ON a.id = sa.articulo
WHERE a.estado = 'a' ORDER BY a.descripcionGracias por la info acerca del proveedor, ya me dispongo a leerla.

[seba123neo]

bueno lo primero que veo es que si le sacas el ORDER BY la consulta baja de 8 segundos en mi pc a 2 segundos. igual 2 segundos es mucho, lo que pasa es que el LEFT JOIN te trae tambien los nulos, los que no coinciden en la relacion, fijate que si le pones el INNER JOIN la consulta es instantanea, ya que ignora los nulos. capas que le podrias dejar el INNER JOIN y despues desde el programa chequear que si ese articulo no esta en ese resultado pues entonces es porque no tiene precio.

[Jeronimo]

Lo que sucede la consulta que puse está simplificada. La que debo hacer en realidad debe incluir los rubros y subrubros (como en la consulta anterior). Y como no todos los artículos tienen asignado un rubro o un subrubro, debo poner sí o sí un LEFT JOIN (por lo menos en esta parte) y temo que eso también pueda ralentizar la consulta.
Voy a probarlo y luego te cuento.
¡Gracias!

Jerónimo

[raul338]

Y si pruebas paginando? Pones por ejemplo los primeros 100, muestra los campos, y despues seguis rellenando

[Jeronimo]

bueno lo primero que veo es que si le sacas el ORDER BY la consulta baja de 8 segundos en mi pc a 2 segundos. igual 2 segundos es mucho, lo que pasa es que el LEFT JOIN te trae tambien los nulos, los que no coinciden en la relacion, fijate que si le pones el INNER JOIN la consulta es instantanea, ya que ignora los nulos. capas que le podrias dejar el INNER JOIN y despues desde el programa chequear que si ese articulo no esta en ese resultado pues entonces es porque no tiene precio.

Sigo sin resolverlo. En teoría, una consulta sencilla como esa, ¿no debiera ser instantánea? ¿Cuál es el error en el diseño de las tablas?

Y si pruebas paginando? Pones por ejemplo los primeros 100, muestra los campos, y despues seguis rellenando

Lo pensé. Incluso lo sigo considerando si no puedo resolverlo de otra manera. Pero me da bronca tener que salir con una solución así por no poder encontrar en qué me equivoqué al diseñar la base (porque para mí se trata ni más ni menos que de eso).
¡Muchas gracias!

[seba123neo]

create un indice en la tabla de stockarticulos de tipo UNIQUE y ponele el campo "articulo" (que es el que usas en el JOIN) y listo, la consulta es instantanea.

[Jeronimo]

¡EXCELENTE!  Funciona de maravillas, ¡rapidísimo!
Amigos, muchas gracias por toda su ayuda. Además de solucionar problemas estoy aprendiendo con ustedes.
Y seguiré investigando este tipo de cosas de las bases de datos para poder solucionar problemas similares sin molestarlos.
Saludos a todos.

Jerónimo