![]() |
Optimizar un SP que traspone una tabla Tengo un par de vistas que obtienen ciertos registros de la BD's, pero los obtengo por filas y los requiero por columnas, así que implementé un SP que traspone a mis necesidades la información, pero el problema es que se tarda mucho. Para una consulta que regresa 100 registros, se tarda casi 2 minutos para ejecutar el SP. El detalle es que hago varias concatenaciones por que necesito la información con ciertas características: 1) Debe haber 4 columnas: M, P, T y O adicionales a la de la llave (NoParte). Las 3 columnas primeras son 'unicas y la 4a es el acumulado del resto de los valores del campo "Almacen" 2) La vista puede regresarme 1 o más registros pertenecientes a x número de almacenes, a veces 1 o 2 almacenes, a veces más y en cualquier orden. Para forzar a que siempre se formen las 4 columnas en orden, hago acumulados y concatenaciones. Si alguien pudiera darme una idea de como optimizar el SP, se lo agradecería mucho, el SP es el siguiente: Código: CREATE PROCEDURE sResumen_Assort_Inventario |
Checa que las tablas que son llamadas por tus vistas vw_Assort_Esp y vw_Assort_Inv tengan NoParte en un index. Mas que eso... cambiar a SQL 2005, nomas... |
Las llaves estan correctas .... y según las pruebas que he hecho, SQL Server 2000 me da mejor desempeño que SQL 2005..... lástima |
:pensando: El problema que yo veo master, son muchos cursores, entiendo que tienes que recorrer esos registros para hacerlos columnas, se me ocurre que si ya tienes tus vistas, puedes hacerle individualmente un group by al o los campos necesarios todo esto dentro de un select, no se que tanto mejoraría el rendimiento contra lo que ya tienes, y tampoco si realmente funcionará, pero algo tenía que decir :borracho: Ya nos contarás más cosas... |
mmmmmmmmmmmmmmmmm, pues no se, sería cosa de probar.... aunque te diré, en este momento estoy peleandome con una vista con no menos de 10 subconsultas y regresa 2000 registros perfectamente procesados en menos de 3 segundos. Por eso la extrañeza de el uso de esos 3 cursoritos anidados con tan pocos registros. Por cierto .... ¿cómo diablos podría hacer para generar una columna con un consecutivo de número de registro en una consulta agrupada? .... sorry, es que no era solo una expresión eso de que me estaba "peleando", jejeje Saludos y dejame "mastico" la sugerencia |
Cita:
Creo que eso se traduce a lo mismo que lo que estás intentando para transponer tus registros verdad? Se me acaba de ocurrir una idea...quizás en lugar de recorrer esos sets con cursores podrías tratar de usar tablas temporales y entonces hacer tus iteraciones a partir de ellas, me parece que sería más rápido...:pensando: deja hago unas pequeñas pruebas. |
No alcanzo a entender exactamente que es lo que pretendes lograr (por tanto cursor), pero creo que algo como esto se aproxima a lo que necesitas: Código: SELECT |
Cita:
Cita:
Supongo que ahora en lugar de gastarle tiempo al SP, mejor se lo dedico a la consulta :arriba: machas thanks y bueno, si alguien alguna vez necesita el algoritmo que transponga una tabla de filas a columnas, el SP que publiqué al principio lo hace, la idea supongo que esta bien: Leer las filas, formar la consulta, concatenar y ejecutar consultas UNION, aunque seguramente debe haber otra forma. Ahora que tenga chance (oportunidad) veré como optimizar el caso de la tranpuesta, por ahora creo que me regresaré a la consulta. Les debo unas birras :borracho: :arriba: (te las perdiste Mith, hasta el otro año en San Marcos) |
| La zona horaria es GMT -6. Ahora son las 21:51. |
Desarrollado por vBulletin® Versión 3.8.7
Derechos de Autor ©2000 - 2026, Jelsoft Enterprises Ltd.