Hola Ivan, el tema es el siguiente: Dentro de las muchas operaciones que la empresa debe hacer es controlar que su mercancia, sea recolectada, embarcada, transportada, entregada y recolectar las pruebas de entrega. Las entregas de la mercancia en mi pais oscilan entre 24 horas e incluso una semana o mas. Hay que tener en cuenta un sinnumero de eventos que pueden llegar a ocurrir. El tema es que aqui cada paquete, cada carta, cada transporte es unico y a nivel operativo no es viable sumarizar (esto solo se haria para estadisticas), pero para custiones operativas no es viable. A ciertas personas les interesa unos periodos largos de tiempos y a otros solo les debe interesar unos periodos cortos de tiempo. El tema es que hablar de periodos largos y cortos basado en la cantidad de informacion que se maneja es muy relativo.
El 28 de marzo de 2012 14:40, Ivan Perales M. <[email protected]>escribió: > Tal vez mi comentario esta un poco fuera de lugar, pero por no dejar ahi > va. > > Realmente esta entretenido lo que pretendes hacer, pero la verdad es que > ni si quiera el director de logistica va a browsear 1 millon de registros, > es mas ni si quiera 50 mil, por experiencia propia de puedo decir que los > gerentes y directores les gusta la información bien digerida. Tal vez estas > atacando el reporte o consulta que quieres mostrar de forma errónea, puede > ser mas interesante generar una gráfica con los resultados o alguna otra > forma visual de ellos. > > Me disculpo de antemano si es lo que pretendes con los resultados. > > Saludos > > > On Wed, Mar 28, 2012 at 1:33 PM, Carlos Edward Grajales < > [email protected]> wrote: > >> mmm atendiendo a la solicitud de Alejandro, la verdad la funcion que hice >> no tiene nada del otro mundo, al momento solo estoy evaluando datos para >> revisar el comportamiento de las cosas. >> >> cree la siguiente funcion: >> >> CREATE OR REPLACE FUNCTION public.fpl_queryanalyze(s_query text) >> RETURNS SETOF record AS >> $BODY$DECLARE >> s_query ALIAS FOR $1; >> r_record RECORD; >> >> BEGIN >> >> FOR r_record IN EXECUTE 'EXPLAIN '||s_query LOOP >> RETURN NEXT r_record; >> END LOOP; >> >> RETURN; >> >> END$BODY$ >> LANGUAGE plpgsql VOLATILE; >> ALTER FUNCTION public.fpl_queryanalyze(text) >> >> >> y la ejecuto asi: >> >> SELECT substring(substring(c,position('rows' in c)+5),1,position(' ' in >> substring(c,position('rows' in c)+5))) as filas >> from fpl_queryanalyze('query') as (c text) limit 1; >> >> Donde query es la consulta a ejecutar. >> >> Reitero, solo lo tengo a manera de pruebas. >> >> La empresa para la cual necesito esto, es una empresa de transporte de >> mercancia, masivo, paqueteo y de mensajeria. >> La cantidad de registros que mueven el transporte de masivo y de paqueteo >> por dia son relativamente bajos (unos 5000 registros a lo maximo), pero el >> de mensajeria es alto. Esta modalidad basicamente es la que se encarga de >> controlar el envio de correspondencia de empresas de telefonia celular, >> facturas de servicios publicos, de entidades del estado y demas, >> diariamente, por este concepto se hacen unos 50.000 ingresos de informacion >> a la base de datos. >> El software se encarga de controlar todo el proceso. y existen unos >> informes que extraen la informacion del sistema y unos de los filtros >> importantes son las fechas en los que los movimientos se realizaron. >> Todos los usuarios del sistema pueden utilizar los mismos informes, pero >> no es lo mismo, que el informe lo genere el director de logistica al cual >> le interesa saber lo que ha pasado con la empresa en un rango alto de >> fechas (1 año, 6 meses ) lo cual puede generar millones de registros, o >> generar la cartera de la empresa a nivel nacional (para saber cuanto dinero >> falta por recoger a nivel nacional). A que el mismo informe lo genere un >> funcionario normal de la compañia. Ud se preguntaran, pero aqui es cuestion >> de perfiles!!!, puede ser, pero igual, los perfiles funcionan y si un >> usuario toma cualquier informe y le da como filtro un rango de fechas alto >> entonces vamos a llegar al mismo punto. La idea no es limitar la >> funcionalidad de los informes, es buscar que los usuarios finales usen los >> filtros adecuados para obtener la informacion adecuada y no saturar el >> servidor con consultas inoficiosas y generar trafico no deseado. >> Cabe aclarar que hoy dia tengo al rededor de 5000 usuarios (no >> concurrentes) pero que ingresan a diario al sistema y generan informes y >> consultas al mismo. El numero de usuario tiende a crecer con el paso del >> tiempo, pues la empresa esta abriendo sucursales en todo el pais ademas que >> los clientes de la empresa tambien tienen ciertos accesos a la plataforma. >> >> >> >> Espero haber sido lo mas detallado posible. >> >> >> >> >> El 28 de marzo de 2012 13:56, Alvaro Herrera >> <[email protected]>escribió: >> >> >>> Excerpts from Alejandro Carrillo's message of mié mar 28 15:41:33 -0300 >>> 2012: >>> > ¿Bueno y si más bien das acceso a ese rol solamente a un function que >>> tenga un limit en el select no impactaría igual o menos que el explain? >>> >>> No, porque la idea no es "entregar a lo más 50000 registros", sino "si >>> la consulta retorna más de 50000 registros, no ejecutarla". >>> >>> -- >>> Álvaro Herrera <[email protected]> >>> >> >> >> >> -- >> ___________________________________________________ >> >> Cordialmente, >> >> Carlos Edward Grajales >> Colombia Software Ltda. >> Calle 18 N No. 3N-24 Ofc.902 >> Cali - Colombia >> www.colombiasoftware.net >> Cel. 313 765 0594 >> Tel: (2) 489 79 40 >> >> > > > -- > Lindolfo Iván Perales Mancinas > Solo existen 10 tipos de personas en el mundo, las que saben binario y las > que no. > -- ___________________________________________________ Cordialmente, Carlos Edward Grajales Colombia Software Ltda. Calle 18 N No. 3N-24 Ofc.902 Cali - Colombia www.colombiasoftware.net Cel. 313 765 0594 Tel: (2) 489 79 40
