FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
#1
|
|||
|
|||
SQL inventario
Hola amigos, alguna idea para mejorara esto...
Tengo una consulta SQL, que demora aproximadamente 15 segundo en devolver resultados. Esto empezo a ocurrir mientras mas registro tengo en mi base de datos. Este es el codigo que utilizo.
Es muy larga... alguna idea para hacerla mas eficiente. Lo que hace es: Busca los codigos en la tabla insumos (aproximadamente 1000 registros), utiliza estos codigo en la tabla inventario dado que la suma de todos los ingresos, menos la suma de todos los egresos. (calcula la cantidad de existe de cada uno de los insumos). Además para cada uno de los insumos calcula el precio pondera, segun la sumatoria de los ingresos por su precio, menos los egresos por su precio. UFFFF.... bueno, el tema es que esta funcionando, pero es muy relento.... unos 15 segundo en entregar la info. Que me dicen ustedes, valdra la pena mejorar esto? Como lo puedo hacer? Alguna idea? Gracias anticipadas. |
#2
|
|||
|
|||
Ya intentaste utilizar indices para las tablas, eso hace las busquedas mas rapidas, ademas por que no haces eso de la suma en un procedimiento por que veo que haces el mismo query como 20 por ejemplo este
SELECT ID FROM BODEGA WHERE NOMBRE ='+quotedstr(scombobox1.text) eso lo podrias ejecutar en un solo query antes que lo demas[FONT=verdana,geneva,lucida,'lucida grande',arial,helvetica,sans-serif], guardarlo en una vaiable y despues utilizar la variable, igual con este [/font]SELECT COALESCE(sum(cantidad),0) FROM inventario i WHERE I.id=M.cod_insum and (tipo ='+QUOTEDSTR('E') |
#3
|
||||
|
||||
Nunca habia visto una consulta taaaaaaan larga, me parece que el diseño de la misma es deficiente ya que utilizas al parecer varias consultas anidadas. Recordemos que las consultas anidadas se realizar por CADA consulta principal que la llame, de ahí el motivo de que mientras más registros más tarda la consulta.
Una consulta bien diseñada no debe de ser afectada por el número de registros que se tengan. Por otro lado, no siempre se puede solucionar todo con una sola consulta, a veces es necesario hacer 1 o 2 más y hacer el proceso directamente en nuestro sistema Delphi. Revisa los selects anidados que pones para saber que bodega es la que estas consultando, me parece que ahi tienes el error. Te recomiendo que primero hagas un solo select para obtener el id de la bodega que el usuario seleccionó y una vez obtenido, solamente sustitúyelo en todos los selects que pusiste. Algo así:
revisa el tema de parámetros también te puede simplificar la vida. No recuerdo si IBQUERY se comporta igual que TZQuery (de Zeos) que automáticasmente crea los parámetros de acuerdo con el código SQl que uno le ponga. Aún así todavía hay querys anidados que no les veo razón de ser.
__________________
AKA "El animalito" ||Cordobés a mucha honra|| |
#4
|
|||
|
|||
Yo tambien pienso que ese SELECT esta muy largo y con toda la pinta de deficiente; pero para ser honesto esta muy largo que no me puse a ver todo lo que pide y si realmente esa es la unica manera de hacerlo.
Pero veo que utilizas un tan solo WHERE con todas las condiciones (amarradas usando infinidad de ANDs) y select anidados para seguramente relacionar tablas, obtener y resumir datos, y todo lo que se necesite. Cita:
Lo primero que deves de dominar es enlazar las tablas usando indices esto se hace enlazandolas usando INNER JOIN, despues deves en UNA SOLA PASADA resumir la tabla de inventarios por codigo usando los criterios que necesites, y despues linkear ese resultado con la tabla de insumos para obtener el listado final. Última edición por Bpascal fecha: 17-01-2009 a las 03:00:37. |
#5
|
|||
|
|||
Esta medio complicado esto parece, les expongo otro ejemplo que me esta ocurriendo lo mismo.
Que es lo que me entrega. Un listado de las distintas area, con su respectivo sumatoria de montos de ordenes de compra y la cantidad de ordenes con presupuesto escedido. Como puedo mejorar esta consulta SQL para que sea mas eficiente. La verdada es que no entiendo muy bien como opera el iiner joi, ni menos si es que me puede servir en mi caso. Bueno los dejo aer si me ponene un ejemplo de como quedaría mi consulta agregando alguna mejor idea. Saludos |
#6
|
||||
|
||||
Selects anidados por doquier, proba metiendolos en un procedimiento para minimizar el numero de selects y poder utilizar mejor los planes (PLAN). Yo tenia una consulta muy exigente tambien y opte por generar tabla temporal para la consulta pase de 2min a 2seg en el rendimiento. te estoy hablando de una consulta que ataca a mas de 6millones de registros.
|
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Facturación e Inventario | silver07 | Conexión con bases de datos | 49 | 22-10-2015 19:45:33 |
SQL inventario | mjjj | SQL | 7 | 12-12-2008 17:13:29 |
Aplicacion + Inventario | mjjj | Varios | 8 | 03-11-2008 15:58:54 |
Costo de Inventario | NickName | SQL | 4 | 09-10-2006 06:30:31 |
Inventario de Hardware | vichovi | API de Windows | 3 | 03-01-2005 15:35:10 |
|