From: | Germán Poó Caamaño <gpoo(at)ubiobio(dot)cl> |
---|---|
To: | pgsql-es-ayuda(at)postgresql(dot)org |
Subject: | Re: Estrategias de recuperacion |
Date: | 2005-06-21 16:42:01 |
Message-ID: | 1119372121.27204.33.camel@cronos |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Le mardi 21 juin 2005 à 11:46 -0400, Alvaro Herrera a écrit :
> On Tue, Jun 21, 2005 at 11:24:41AM -0400, Fernando San Martín Woerner wrote:
> > Damas y Caballeros(Con o sin caballo):
>
> Sin caballo por ahora, gracias.
>
> > Durante el tiempo que he desarrollado con postgresql, y otras DB siempre
> > me he encontrado con un problema que puede resultar lastimero. Tal
> > problema es el recuperado de datos por parte de la aplicación. Como caso
> > pongo el ejmplo de un listado de clientes, el cual esta muy ordenado y
> > supongamos tiene 10.000 registros, al momento de querer utilizar esa
> > lista en un control de combo o autocompletado siempre resulta lento
> > tener que cargar esa cantidad de datos en memoria, supongamos que
> > tenemos combos para los RUT(DNI o identificacion personal) y para
> > nombres, nuevamente el cargar controles graficos con tal cantidad de
> > datos toma tiempo. Por otra parte las aplicaciones que no tienen
> > opciones de busquedas sencillas y poderosas se vuelven más díficiles de
> > usar. Ahora el punto a discutir es alguna estrategia que permita
> > recuperar estos datos y que no haga más lenta la aplicación.
>
> Una posible idea seria tener una caja de texto donde el usuario puede
> poner un prefijo, y en la BD usas eso para la primera busqueda.
> Ingresando las primeras dos o tres letras ya se restringe bastante, y en
> el combo tienes que poner menos elementos.
>
> (Por otro lado despues los usuarios querran hacer busquedas de
> substrings, y ahi quizas se ponga mas complicada la cosa, puedes
> implementar busquedas por trigramas, contrib/pg_tgrm).
Un esquema que podría emplear, es no cargar todos los datos en
un componente gráfico. Para qué mostrar 10.000 registros, si
en la pantalla no te caben más que 30 (por decir un número).
Luego, se pueden cargar de 100, 200, 300 ó 1000. Y el resto
cargarlos en demanda.
En todo caso, 10.000 no me parece que sean muchos; aunque
suficiente para dejar la barra de scroll completamente
inservible.
Es más, almacenar esos 10.000 registros en memoria no es un
problema, sino hasta que se intentan dibujar en un componente
gráfico.
--
Germán Poó Caamaño
http://www.ubiobio.cl/~gpoo/
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2005-06-21 16:44:40 | Re: consulta |
Previous Message | Jairo Sánchez | 2005-06-21 16:34:24 | Select con dos bases de datos |