Sugerencias para agilizar SELECT. Incluir JOIN?

[Zarlu]

Buenas tardes foxeros!

Tengo una búsqueda que tarda espantosos segundos y creo son demasiados para el volumen de registros

VFP9 SP2

Tengo dos tablas nativas:
Tabla:testis&&15000 registros de los cuales 726 cumplen la condición de ubicación
campo exped&&tiene indice
campo ubicacion&&tiene indice

Tabla: recep&&50000 registros
campos: exped&&tiene indice
campos escritura&&tiene indice

Requiero por cada registro de la tabla testimonios con ubicación="X", obtener el campo escritura de la tabla recep

Ya probé estos códigos:
Select testis.exped, recep.escritura From testis, recep Where testis.exped==recep.exped .and. testis.ubicacion Like "%X%"

Select  testis.exped, recep.escritura From testis JOIN recep ON recep.numexped==testis.expediente;
 .and. testis.ubicacion like "%X%";
*-aquí ya alterné tabla derecha e izquierda, ya probe left join y right join

Gracias

zarlu

Chetumal, Quintana Roo, México

[Carlos Miguel FARIAS]

Aunque tengan índices las tablas, antes de efectuar el SELECT, ¡desactivarlos!

La ubicación es igual a "X", o debe contener una "X"?

Si tiene que ser igual, mejor codificar testis.ubicacion = "X"

Si eso es correcto (igual a, y no que contiene) un índice sobre testis.ubicación puede mejorar algo (sobre todo si un % < 20% cumple con ese requisito)

Rushmore usa los índices que existan pero no tienen que estar activados. El activa por su cuenta los índices que les sirva o crea algunos temporales

Saludos: Miguel

--
Visita el Blog de la Comunidad Visual FoxPro en Español: http://comunidadvfp.blogspot.com
---
Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/2cf8e11f-f0c5-4db8-9181-2f1d9be2d95cn%40googlegroups.com.

[Zarlu]

Gracias Miguel!

Probadas todas tus sugerencias.

Sigo igual

zarlu

Chetumal, Quintana Roo, México

[Luis suescún]

inner join también?

si la bd está normalizada y debería de haber integridad referencial entonces el inner join mejora mucho

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/69d84ead-ce5a-4aad-a8df-8568fcbe5ad8n%40googlegroups.com.

[Carlos Miguel FARIAS]

Pero el filtro es sobre  testis.ubicacion Like "%X%" o  testis.ubicacion = "X"?

recep.numexped es el que usas para asociar las tablas pero dices que tienes índice recep.exped? Es un error cortar y pegar o realmente es así?

La consulta es en una máquina local o sobre un servidor?

El disco está de-fragmentado? (Por experiencia, procesos de 15' se extendía a 5 o 6 horas solo por estar el disco fragmentado).

Saludos: Miguel

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/CALB_FW7N-yAtR6obHMQ92TeD668oaQejmFuK40LtMm%3DSm6YQag%40mail.gmail.com.

[ggcagnola gmail]

el like ES LENTO siempre...

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/CACqOu4zkpkr4jaUBQppZy2Jb7RBXJafxeMYdRdV7aT21-KYpyg%40mail.gmail.com.

[Antonio Lima]

Hola a Todos,

ggcagnola tiene razón ,  los likes siempre son lentos ( son secuenciales)

Pero puedes probar esto:

Primero que nada ambas tablas deben de estar indexados por los campos testis.Expediente  y recep.NumExped  

Si crees que no hay muchos registros de ubicación para cada Expediente puedes hacer un select con subconsultas  

por ejemplo primero obtener todos los registros que  testis.Expediente  == recep.NumExped    y luego hacer una consulta con el like 

select * from (

select testis.exped, recep.escritura from testis

inner join recep on recep.NumExped = testis.Expediente ) tmp

where tmp.ubicacion like "%X%"

Saludos,

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/674b369b-2890-230c-e89c-8b0cd4a6449a%40gmail.com.

[Carlos Miguel FARIAS]

Si, iba a proponer lo mismo, pero si lees lo que plantea, los indices estan sobre exped, y conecta con exped cuando junta desde el where y usa otros campos con el join.

Ahí al menos hay una inconsistencia de enunciado.

Mejor que aclare, porque posiblemente lo que le propongamos no tiene nada que ver con lo que plantea (por error en el planteo)

Saludos: MIguel

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/CAGPJKZG13h%2BPcz3zFHdm4%3DVEfp3MDZ6T0y_nRHNZeBOxE6fB9Q%40mail.gmail.com.

[Carlos Miguel FARIAS]

Si, el like que puede ser mejorado un poco es cuando la parte variable es al final, por ejemplo "X%", pero si es "%X%" el índice no sirve y se tiene que comer todos los registros.

Por eso pregunte si era por X contenida o por igual a X (y si el filtro no selecciona menos de un 20% de los registros, tampoco sirve).

Mirando nuevamente lo que das como base observo que:

Mencionas índices sobre exped (en ambas tablas) pero el join lo haces sobre exped (cuando haces filtro completo por where) pero en el join utilizas numexped y expediente

Puedes aclarar?

Saludos: Miguel

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/674b369b-2890-230c-e89c-8b0cd4a6449a%40gmail.com.

[Zarlu]

Buenos días foxeros!

Miguel, ggcagnol, ideasgt, luisandrey........gracias a todos!

Estoy por probar sus últimas sugerencias.

Si hay un problema de planteamiento en el segundo select, DISCULPENME. Los campos e índices "exped" son iguales

Ya probé estos códigos: (aquí corregido)

Select testis.exped, recep.escritura From testis, recep Where testis.exped==recep.exped .and. testis.ubicacion Like "%X%"

Select  testis.exped, recep.escritura From testis JOIN recep ON recep.exped==testis.exped;

 .and. testis.ubicacion like "%X%";
*-aquí ya alterné tabla derecha e izquierda, ya probe left join y right join

zarlu

Chetumal, Quintana Roo, México

[Marcos Godoy]

Agrega un indice  asi:

index on deleted() tag borrados

y probá

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/CACqOu4xUVfmBdfpLQyPJTSLbGJ_P-e6qT_hw1QPgdga%2BTzBMkA%40mail.gmail.com.

--

Marcos E. D. Godoy

Alicia Moreau de Justo 1120

te: (54 -11) 5365-8767 Interno 2005

[Zarlu]

Les comento foxeros!
Una sopa de mi propio chocolate...

Tenia el indice sobre Alltrim(ubicacion). No permitía una consulta óptima. No me había percatado.

Mis comentarios:
Los indices sobre Deleted() ya los tenía.
Desactivarlos (SET ORDER TO) no es relevante. Como menciona el colega VFP usa los que optimicen.
Incluir una subconsulta lo demoró más
Funcionó mejor usando "<>" en lugar de "like" ó "="
No usé JOIN (en sintaxis)

Logré optimizar la consulta. Aunque la rapidez no depende sólo de eso.

Reduje el tiempo en primera ejecución de .1167 segundos hasta .0333

Éste artículo me ha servido antes se los dejo de nuevo:
https://comunidadvfp.blogspot.com/2014/09/visual-foxpro-y-la-optimizacion-rushmore.html

Gracias a todos

zarlu

Chetumal, Quintana Roo, México

[HernanCano]

Bien, muy bien, Zarlu.

Estoy haciendo también unos estudios (sobre un caso particular), y esta info me sirve a lo grande.

Gracias por compartir.

[Antonio Lima]

Excelente noticia, y un buen trabajo.  Lo que sería ideal es que pudieras compartirnos la consulta, y cómo has sacado la imagen.   la consulta es realmente sencilla me ha quedado duda como la has optimizado.

Un saludo

--
Visita el Blog de la Comunidad Visual FoxPro en Español: http://comunidadvfp.blogspot.com
---
Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/9c50c574-66ec-4045-966d-e2b943666423n%40googlegroups.com.

[Zarlu]

Buenos días ide...@gmail.com!

En mi consulta el detalle principal era que tenía un indice formado con Alltrim(ubicación). Eliminé Alltrim(). Eso me permitió optimizar

(Comentario: la estructura de las comparaciones de la búsqueda debe ser semejante a la del índice y opino es mejor no usar funciones)

Y como dice el artículo los índices sobre Deleted()

La sintaxis final quedó así:

Select testis.exped, recep.escritura From testis, recep Where testis.exped=recep.exped .and. testis.ubicacion<>"ENTREGADO"&&el código inicial era "Like "%ENTREGAR%"

El código para obtener el resultado de optimización es:

lcIni=Val(sys(2))
=SYS(3054,11,"cmemvar")

*aquí el Select * From...

? cmemvar
?
? "Tiempo: "
?? (Val(sys(2))-lcIni)/60.

Optimización no precisamente es velocidad, pero es ideal. También intervienen otras cuestiones físicas (red), tamaño de la información, sintaxis del select.....

zarlu

Chetumal, Quintana Roo, México

[mpulla]

Hola Zarlu.

Como recomendación, la sintaxis con que escribes Sql es ANSI-89, para ANSI-92 y posteriores se usa Inner Join, Left Join, etc. es mas legible y el rendimiento no se ve afectado.

Saludos.

Mauricio

[Zarlu]

Buenas tardes jmaur...@yahoo.es !

Se te agradece.

Si percibí una diferencia de rendimiento, pero MUY mínima y por costumbre opté por la "vieja" sintaxis que lleva implícito un join.

zarlu

Chetumal, Quintana Roo, México