Consultas o Filtros ....

[JULIOCTORRESG]

Por alli vi que Caral preguntaba sobre la eficiencia o no de los filtros , repregunto porque fue en otro hilo y nadie dio su opinion al respecto ....

la cosa va asi ...tengo un modulo en el cual tengo una consulta que se activa en el evento onchange del un tedit ....asi rellena un grid y selecciono lo que busco dicha consulta funciona como es de esperar con like

select campo,campo2,campo3
from tabla
where campo like +''''+'%'+'TEdit1.Text'+'%'+'''');

la cosa no se ve mal es es bastante rapida a pesar de que la tabla tiene algo asi como 2 mil a tres mil registros pero quiero optimizar que tal si en vez de esto de llamar una y otra vez la consulta a dicha consulta aplico un filtro ....sera que mejora el rendimiento .....

esa es mi pregunta.....


gracias ante todo........

[Neftali [Germán.Estévez]]

Si vas a realizar muchas consultas, tal vez en este caso, te sería más adecuado traerte toda la tabla a memoria de una vez e ir haciendo búsquedas en local.
Se trata de hacer la comparación entre:
* Traer toda la tabla de una vez y no volver a generar tráfico con las consultas
* Ir ejecutando consultas filtradas; Traen menos datos, pero ejecutas más.

Depende del número de consultas que ejecutes en media, te saldrá a cuenta una u otra.

[Lepe]

Yo siempre digo lo mismo, no abusar del evento OnChange, basta que entre un administrativo con 400 pulsaciones por minuto para que tu programa empiece a temblar ;).

Igual de cómodo para el usuario, pero usando el evento Onkeydown:


if key = vk_return then
hacer la busqueda


Así solo se pide la consulta al presionar la tecla intro, repito, cómodo para el usuario y eficiente para la Base de Datos.

Saludos

[Neftali [Germán.Estévez]]

Yo siempre digo lo mismo, no abusar del evento OnChange, basta que entre un administrativo con 400 pulsaciones por minuto para que tu programa empiece a temblar

Totalmente de acuerdo.

[Lepe]

Respondiendo directamente a tu pregunta:

Normalmente cuando se habla de Filtros no quiere decir que usemos Filter y Filtered, estamos diciendo que se aplica alguna restricción a los datos mostrados.

La consulta casi siempre será más eficiente que un Filter. Con Filtered debe viajar todos los registros de la base de datos al cliente (da igual si solo tienes un ordenador), en realidad estas seleccionando todos los registros de la base de datos y después, se aplica la restricción. Si tienes un servidor bastante apurado, quizás sea mejor la opción de Neftali.

En una tabla con 2.000 registros, si buscas a un tal "pepe" con una consulta estas pidiendo 4 o 5 registros como mucho, con Filter estas pidiendo los 2.000 y después aplicar la restricción. Como ves, aun cuando tengas que hacer 3 o 4 consultas porque no encuentras los resultados que quieres, siempre viajará menos información.

Saludos

[JULIOCTORRESG]

Hola amigos gracias por sus respuestas y aprovecho para aclarar y repreguntar ....

la cosa funciona asi, yo tengo una consulta la cual se trae todos los registros(segun yo creo y si no please haganmelo saber..) en ese momento tengo todos los registros en memoria (si o no ...?) a este conjunto de registros ya en "memoria" es a quien aplico el filtro y por eso deberia ser eficiente porque el filtro se aplica a un conjunto de datos que esta en memoria o sea no me reconecto con el servidor ...o si..?

segun yo creo en mi ignorancia la cosa funciona asi, porque si no que sentido tienen los filtros en ese caso las consultas son infinitamente mejores ....


esto si que es urgente porque si estoy equivocado debo corregir algunos errores ....

gracias mil .....

[Neftali [Germán.Estévez]]

Deberías explicar cómo estás leyendo los datos y cómo estás aplicando los filtros.
Si cada vez ejecutas un Select (como dices en el post inicial) está claro que no estás filtrando en local. Cada vez estás trayendo los datos (todos o parte de ellos) que corresponden a esa SQL.

[Lepe]

También deberías explicar el contexto, ya que si piensas ejecutar un filtro cada 2 segundos, pues oye, el filtrado en local será mejor que andar pidiendo datos al servidor.

La única desventaja que tiene los filtros en local, es que no están sincronizados con el servidor, es decir, si alguien agrega un registro, con el filtro local no lo vas a ver jamás.

Saludos

[JULIOCTORRESG]

en efecto si realizo select cada rato en ese caso la consulta no es local eso lo tengo claro, pero lo que quisiera es

llamar a la consulta por ejemplo en el activate del formulario...
y luego segun el contenido de un tedit filtrar la data de la consulta la pregunta es ....al filtrar es sobre la data local o sea en memoria producto de la consulta que se trae todos los datos ....

todo esto porque mi consulta(futuro filtro ) es sobre un tedit en el evento onchange(que porque aca porque asi lo quieren ...donde manda capitan ...) y la idea es hacer mas eficiente el uso de la red ....


gracias mil por sus respuestas

[Lepe]

Si la consulta es del tipo:

select * from clientes order by nombre

Si obtendrás todos los datos (en memoria mientras la consulta se mantenga abierta). Después solo tienes que usar locate por ejemplo, para buscr dentro de esa consulta.

Ahora eres tú personalmente el que tiene que sopesar las contraindicaciones.
Si ese "cada rato" es cada 3 segundos, pues sí, te diría que aplicaras filtros en local. Si es un edit que solo se usará 2 o 3 veces y necesita estar informado de los nuevos registros que se den de alta, no tendrás más remedio que usar una condición where en la consulta.

Saludos

[Neftali [Germán.Estévez]]

Si no quieres tener la consulta abierta, puedes usar TClientDataSet para trabajar en memoria.
Cargas los datos en local, cierras la consulta y luego puedes trabajar (filtrar, ordenar,...) sobre esos datos en local.
No hace muchos días hemos estado en un par de hilos hablando del tema, incluso puedes encontrar algun ejemplo.
Busca en los foros hilos recientes sobre el tama.

Un saludo.