Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Bases de datos > Firebird e Interbase
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 22-06-2007
Gregory Mazon Gregory Mazon is offline
Miembro
 
Registrado: jun 2003
Posts: 22
Poder: 0
Gregory Mazon Va por buen camino
Gracias por todos sus comentarios

ya estube haciendo pruebas con lo que me han comentado, ya le quite la funcion BETWEEN tal como lo dice eduarcol, ya le quite el Left tal como dice Delfino. Me falta hacer la prueba con Firebird, y ya cheque que mis indices esten correctos, y si es verdad mejoro mi consulta en vez de tardarse 10 minutos como antes ahora se tarda 3 minutos, no se si todavia se pueda mejorar con Firebird lo voy probar, pero aqui una de las cosas q mas me preocupan es que estos 3 millones de registros son solo de informacion de solo 5 meses (es el tiempo que lleva funcionando el sistema), que va ha pasar con informacion acumulada de 1 o 2 años, por q pretenden tener reportes comparativos de cuanto se vendio el 21/jun/07 vs. el 21/jun/08.

Cita:
Empezado por Neftali
Revisa el plan de ejecución si es posible para ver lo que se está haciendo y los tiempos de las distintas operaciones.
Que es el plan de ejecución como los debo de interpretar?
Utilizo el IB Expert Personal Edition y cuando hago mi consulta en la parte inferior me regresa:
Código:
Plan
PLAN SORT (MERGE (SORT (DR REM INDEX (REMISION_IDX1)),SORT (JOIN (DR DR NATURAL,DR ART INDEX (RDB$PRIMARY1)))))

Adapted Plan
PLAN SORT (MERGE (SORT (DR REM INDEX (REMISION_IDX1)),SORT (JOIN (DR DR NATURAL,DR ART INDEX (PK_ARTICULOS)))))
Responder Con Cita
  #2  
Antiguo 22-06-2007
Avatar de Lepe
[Lepe] Lepe is offline
Miembro Premium
 
Registrado: may 2003
Posts: 7.424
Poder: 29
Lepe Va por buen camino
En la propia ayuda de IB Expert viene que al usar un plan "NATURAL" realmente no se está usando índices, por tanto sería una consulta NO optimizada.

Según explica hay veces que es mejor no usar índices (aún cuando existan) porque la tabla es pequeña y el uso del índice lo hace tardar más.

Como ves yo ando buscando información sobre el tema, pero no puedo hablar mucho.

Saludos
__________________
Si usted entendió mi comentario, contácteme y gustosamente,
se lo volveré a explicar hasta que no lo entienda, Gracias.
Responder Con Cita
  #3  
Antiguo 25-06-2007
Delfino Delfino is offline
Miembro
 
Registrado: jul 2003
Ubicación: Madrid
Posts: 974
Poder: 21
Delfino Va por buen camino
Puedes poner el plan de antes de quitar el left y despues? asi podremos ayudarte a leerlo y interpretarlo,
como dice lepe, natural significa q escanea todas las filas,
basicamente en un plan la informacion mas valiosa es cuando un indice se usa o no, y por cierto usando los indices adecuadamente daria igual q cantidad de registros hay, el acceso es directo..
__________________
¿Microsoft? No, gracias..

Última edición por Delfino fecha: 25-06-2007 a las 16:13:46.
Responder Con Cita
  #4  
Antiguo 25-06-2007
Gregory Mazon Gregory Mazon is offline
Miembro
 
Registrado: jun 2003
Posts: 22
Poder: 0
Gregory Mazon Va por buen camino
Gracias, con el Left me muestra lo siguiente:
Código:
Plan:
PLAN SORT (JOIN (DR DR NATURAL,DR REM INDEX (RDB$PRIMARY16)))

Plan Adaptado:
PLAN SORT (JOIN (DR DR NATURAL,DR REM INDEX (PK_REMISION)))
quitandole el Left me muestra lo siguiente:
Código:
Plan:
PLAN SORT (JOIN (DR REM INDEX (REMISION_IDX1),DR DR INDEX (RDB$PRIMARY28)))

Plan Adaptado:
PLAN SORT (JOIN (DR REM INDEX (REMISION_IDX1),DR DR INDEX (PK_DE_REM)))
con la primer opcion la consulta se tarda 8 minutos, con la segunda opcion la misma consulta se tarda 4 minutos
Responder Con Cita
  #5  
Antiguo 26-06-2007
Delfino Delfino is offline
Miembro
 
Registrado: jul 2003
Ubicación: Madrid
Posts: 974
Poder: 21
Delfino Va por buen camino
Porque en la tabla maestro la clave primaria esta compuesta por dos campos? estas cosas se hacian en tiempos de los dbf,

Se agilizara bastante pero bastante la ejecucion de la query si le pones una clave primaria compuesta por un solo campo ID, y el join se haga por un solo campo, tb creando un indice sobre algun campo de la select, el campo cantidad por ejemplo.

Por cierto, el uso de between no se diferencia en nada a la otra forma, pq internamente el motor se encarga de traducirla, pero between es mejor legible en una consulta..
__________________
¿Microsoft? No, gracias..

Última edición por Delfino fecha: 26-06-2007 a las 10:23:23.
Responder Con Cita
  #6  
Antiguo 26-06-2007
seara2005 seara2005 is offline
Miembro
 
Registrado: ago 2003
Ubicación: Colombia
Posts: 63
Poder: 21
seara2005 Va por buen camino
Ayuda con consulta lenta

Yo no soy experto en estas materias, pero la lógica y mi criterio me dicen que si hoy estas analizando como reducir de 8 a 4 o 3 min la consulta, en un año estarás viendo como reducirla de 20 a 10, etc. por tanto te recomendaría que acotaras la información a procesar para las consultas frecuentes, por ejemplo yo incluiría un campo Inicial por cada información que se necesite de forma tal que al pasar de un mes a otro, el sistema actualice un acumulado hasta ese cierre en este campo y las consultas siguientes estarían acotadas a ese saldo mas los movimientos del mes actual. Así el rendimiento del sistema prácticamente no mermaría con el paso del tiempo ya que las consultas siempre son de operaciones de un mes.
El cierre y asignación de saldos iniciales del mes se hace una sola vez en el período así que no es un problema crítico.
__________________
Saludos

Seara2005
Responder Con Cita
  #7  
Antiguo 27-06-2007
Gregory Mazon Gregory Mazon is offline
Miembro
 
Registrado: jun 2003
Posts: 22
Poder: 0
Gregory Mazon Va por buen camino
Cita:
Empezado por Delfino
Porque en la tabla maestro la clave primaria esta compuesta por dos campos? estas cosas se hacian en tiempos de los dbf,
La razon es por que el sistema esta instalado en sucursales remotas, cada una con su propia BD y a determinado tiempo se replica la informacion a la BD del server, cada una de las sucursales tiene su propio IDTIENDA y para que nota de venta tengo su respectivo ID, por eso la clave compuesta

Cita:
Empezado por seara2005
Yo no soy experto en estas materias, pero la lógica y mi criterio me dicen que si hoy estas analizando como reducir de 8 a 4 o 3 min la consulta, en un año estarás viendo como reducirla de 20 a 10, etc. por tanto te recomendaría que acotaras la información a procesar para las consultas frecuentes
aqui el problema es que no existen consultas frecuentes, sino que las consultas pueden ser dia vs. dia, mes vs. mes, semana vs. semana, como al gerente de ventas se le ocurra, no puedo poner un saldo inicial o saldo final. ahorita lo que estan comprarando es mes vs. mes. (ej. 15/May/07 vs. 15/Jun/07)

Haciendo otra prueba a la tabla detalle le meti el campo FECHA que es el que tengo en la tabla maestro y por medio del cual estoy haciendo el WHERE.
Al hacer mi consulta esta forma me resulta en solo 30 segundos. Aqui es en donde tengo mi problema, pero entonces de que forma deberia de hacer mi consulta?, o para que mis consultas sean rapidas debo de incluir en las tablas de detalle los campos del maestro para no tener que hacer join's?, o cual es la manera de realizar una consulta detalle-maestro?
Responder Con Cita
Respuesta


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
Consulta Super Lenta AGAG4 SQL 4 03-04-2006 19:36:50
Primera consulta, mas lenta que el caballo del malo papulo Conexión con bases de datos 20 23-09-2005 13:46:24
Impresion lenta, muy lenta... Perio Impresión 2 20-05-2005 13:10:00
Consulta muy lenta Walterdf Conexión con bases de datos 2 25-08-2004 18:37:57
lenta la consulta. digital Conexión con bases de datos 2 10-09-2003 15:38:13


La franja horaria es GMT +2. Ahora son las 23:00:01.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi