comprimir resultado de consulta

[cuscus]

hola , mi prgunta es si hay alguna manera de comprimir el resultadoi de una consulta sql, de forma que cuando se trate de una bbdd remota la informacion que viaje por la red sea mucho menor.

muchas gracias

[Rufus]

Sobre comprimir, existe un buen programita, muy sencillo llamado Zebedee, que comprime y tambien encripta, lo cual es muy recomendable para conexiones remotas.

Tienes un manual de uso para firebird aqui: http://firebird.sourceforge.net/down...ebedee_eng.pdf
No es nada dificil configurarlo para que funcione

Aparte de eso, esxisten multiples estrategias para disminuir el trafico de la red. En este foro ya se han comentado algunas veces. Te voy a poner las mas impportantes, las que tienes que saber obligatoriamente:

• NUNCA utilizar componentes al estilo TTable.
• NUNCA hacer consultas del estilo "Select * from tabla". A fin de cuentas seria lo mismo que lo que hace el punto anterior.
• Por tanto, y derivado de lo anterior, hacer consultas seleccionando EXACTAMENTE lo que el usuario quiere encontrar o necesita ver. No solo los registros, tambien los campos de la tabla o tablas, de manera que pasamos de un "Select * from tabla" a un "Select campo1,campo2,campo3 from tabla where.... and ....";
• Utilizar todos los recursos que nos de el servidor de base de datos para que se hagan todos los calculos en el, como vistas, triggers, procedimientos almancenados, etc y que nos devuelva EXACTAMENTE lo que queremos ver.
• Por ultimo, y bajo mi propia experiencia, resulta mas efectivo para actualizaciones, altas o bajas no manejando los metodos del TDataset (como post, cancel y todo esto) sino utilizar procedimientos del servidor o bien directamente pero mediante sentencias SQL directas, como "Execute procedure..." o "Insert into tabla(campos..) values....(valores)...". Aunque esto supone irremediablemente más programación, los resultados mejoran y sinceramente lo merecen. Resumiendo, utlizar lo menos posible el TDataSet y todo el sistema "clásico" de manejo de datos de Delphi, porque éste claramente estaba pensado inicialmente para bases de datos de escritorio, mejor utilizar BDExpress o bien otros componentes pero teniendo MUY en cuenta lo que te digo en este punto.

Por último, he visto un artículo publicado por mamcx en su web donde da unas buenos consejos acerca de la arquitectura a seguir en las aplicaciones de dase de datos.

Un saludo

[cuscus]

gracias por contestar, utilizo unicamente ibquery y las consultas son como tu dices refinadas, osea traigo solo lo que necesito. Asi todo y aun con una conexion buena tarda su tiempo. Al comenzar la ejecucion el tiempo de descarga es asumible ya que el cliente lo entiende, pero una vez el usuario empieza a interactuar con la aplicacion quiere que sea inmediato. Para ello solo me queda trabajar en local y luego actualizar la remota. Esto veo que me supone muchas complicaciones ya que debo controlar si se ha modificado campos, añadido registros, borrado etc osea controlar muchas posibilidades. Sin embargo lo poco que he leido sobre .net , veo que el componente dataset de .net me ahorraria algunas de estas cosas y la aplicacion tiraria contra el dataset que tendria los datos en memoria y seria inmediato y yo le indicaria exactamente cuando actualizarlos en la BBDD. ¿estoy en lo cierto? ¿crees que ante mi problema .net seria la solucion mas adecuada?

[Rufus]

No lo se, no utilizo .net. Te lo podran comentar otros compañeros.

Yo utilizo FIBPlus + DataSnap, y el resultado es satisfactorio. Es decir, que para instrucciones directas utilizo un componente query (similar al tquery de IBX) y para consultas navegables BIDIRECCIONALES utilizo un dataset + datasetprovider + clientdataset, el cual desconecto y mantengo sólo en local tras seleccionar el usuario los datos que desea ver. Las actualizaciones se hacen solo sobre el registro actual. Remarco bidireccionales por que para conjuntos de datos unidireccionales, en los que no hay porque mostrar los datos en un grid navegable o componente similar, es decir, que el usuario no tiene porque ir hacia atras en el conjunto de datos, el mismo query vale.

Eso si, las conexiones tendran que ser de 128 kb por lo menos, si es por modem va a ser lento seguro, ahi ni con .net, mejor entonces hacer replicación o algo por el estilo.