Filter vs consulta SQL
 

Hola. Estoy haciendo una busqueda en una tabla de esas que van apareciendo los resultados a medida que uno teclea, en un dbgrid.
Lo trate de hacer antes con una tabla y mediante filter, pero tuve muchos problemas con las sintaxis por lo que opte por hacerlo con un select like. Ahora mi duda es si cual de los dos metodos es mas optimo, ya que hacerlo mediante un select por cada tecla que presiono implica realizar una consulta a la base de datos por cada tecla, lo cual pienso no debe ser lo mejor, o tal vez sea lo mismo en cuanto a velocidad y rendimiento que mediante el filter.
Alguien me podría contestar esto?
:confused:
Saludos

Nacho

Supongo igual que tu, debe ser mas optimo para tu caso, utilzar filter antes que una nueva consulta SQL.

Creo que en general, lo más óptimo para este caso es traer todos los datos y hacer los filtros en local; Eso también será más ágil de cara al usuario cuando va escribiendo. Para tablas pequeñas, bien.

La excepción es cuando la tabla es grande, en ese caso yo desecharía esa opción (búsqueda incremental) y optaría por utilizar una pantalla de filtro con uno o varios campos antes de realizar la consulta SQL.

Por tu duda parece un campo que guarda el Nombre del cliente / proveedor con la función de Autocompletar.

Otra Solución de escritorio es mapear los registros en un StringList (digamos durante la inicialización del programa) después de insertar / borrar / modificar en la tabla, haces lo mismo en el StringList (sin recargar todos los proveedores de nuevo, solo añadiendo el nuevo), así puedes sincronizar los datos sin sobrecargar a la base de datos.

De vez en cuando se haría necesario la sincronización (recargar TODOS los proveedores de nuevo), ¿mediante un botón?.

Con 5.000 registros tarda 300 milisegundos en mi caso (es aceptable ya que la tabla no tendrá más de 5.000 registros).

Quizás se podría optimizar pensando en el futuro, dejando los proveedores menos usados sin mapear.

Cuando he dicho "solución de escritorio", me refiero a programas monousuarios, obviamente en un entorno de red no podríamos usar esto.

Saludos

Si los registros ya están en local, creo que no es necesario.
Hay DBGrids que lo hacen en local, y sino la búsqueda en un DataSet local utilizando un índice debería ser más o menos igual. En ambos casos, si es un campo clave (y StringGrid ordenado) acabará haciendose una búsqueda dicotómica.

OJO:

Esto funciona muy bien siempre y cuando:

1.- Traigas todos los datos de un golpe
2.- Los datos se encuetren en Local o al menos en la misma red.

Intentalo via IP o WAN y entonces tendrás una lentitud de dolor de cabeza, si traes todos los datos y son miles...imaginate lo que tardara en cargar...si no cargas todos y vas haciendo un SELECT cada que escribes un caracter...igual.

Sugerencia:

Si es una aplicacion remota no uses este concepto del speedsearch, mejor usa el de que el usuario escriba unas cuantas letras del nombre que quiere buscar y haces un "select ....like %dato%" trayendo solo los registros que se parezcan, lo muestras en una lista y el usuario selecciona de ahi. Es más rápido y pontente ya que en el caso que mencionas tiene que escribirse correctamente y en el mismo orden las palabras por ejemplo:
el regitro:
"COMPAÑIA MEXICANA DE VALORES"
para hallarlo con speed search tendria que escribir
"COMPAÑIA MEX"
con el otro esquema:
"MEXICANA DE VAL"
"DE VALORES"
"VALORES"
Nos devolverá una lista donde aparecerá el registro que queremos (incluso solo ese si no coincide otro mas).

re: a varios
 

Respondo a varios a la vez:
1-El sistema va a funcionar en forma local, tal vez a travez de una red, pero una red LAN.
2-Lepe me entendio mal, no es una lista con los mas usados sino una busqueda cuando no quieres ingresar el codigo.
3-En cuanto a Azidrain, es exactamente asi como lo estoy haciendo. La consulta tiene un %usuario% y voy filtrando incrementalmente los resultados (en realidad no filtrando, sino haciendo un select en el evento change del control).

El problema que tuve con el filter, es que no aceptaba la misma sintaxis que utilizo para la consulta SQL y me daba error al utilizar %criterio%

Saludos

Nacho