lentitud en conexion remota con bases de datos

[Casimiro Noteví]

Tú debes pensar en que estás haciendo un cajero de banco, te habrás fijado que todo es muy simple, sólo pide los datos únicamente necesarios e imprescindibles, realiza una transacción y cuando acaba entonces inicia otra, y siempre pidiendo los datos mínimos posible. Pues ponte en la cabeza algo así.
Si vas a pedir el login y la clave, ¿qué datos te traes? 'select * from tbclientes'?, no, no te traes ninguno. Presentas al usuario el form con el login y la clave y luego buscas sólo el login en la tabla: 'select codigo, login from tbclientes where login= :login'. Si existe entonces procesaremos el password según el codigo que traemos en el select'.
Ahora presentas el menú de opciones al usuario y actuaremos según lo que seleccione, por ejemplo, quiere conocer su saldo, entonces como tenemos su código:
'select saldo from tbclientes where codigo= :codigo'. Nada más, que eso, el saldo, no nos ha pedido nada más.
Y así con todo, es un ejemplo a lo 'bruto', pero para que te hagas una idea de que debe ser siempre lo mínimo posible necesario e imprescindible.

[anubis]

Gracias nuevamente por las aportaciones.
Me queda totalmente claro lo que me explicas y sí, voy a necesitar reconstruir la aplicación en lazarus porque, para pocas líneas y en monopuesto funcionaba bien, a pesar de que la aplicacion la hice de "andar por casa" pero al pasar de sqlite a firebird y sobretodo en entorno de red, si tarda algo, y mucho más en forma remota.
Voy a tener que buscar información sobre los procedimientos, vistas, triggers etc de las bases de datos porque ando perdido.

Pero ya os preguntare si me seguís dando opción.

[[AzidRain]]

No creo que tengas que rehacer todo, basta conque le des una manita de gato a todo donde pusiste "select *...", por lo demás te andará bien. Otro consejo, puedes irte olvidando de las tablas como un todo e ir penando en las querys como "la parte de las tablas que necesitas para trabajar en un momento dado" Eso te va a funcionar siempre. Recuerda que un query no es mas que una "pregunta" o "consulta" a una base de datos, quien se encarga de atendertela lo mas rápido posible. El ejemplo que te pusieron de la librería está genial, lo explica todo de una manera muy sencilla. Ah y falta otra cosa, no nada mas tenemos que filtrar bien los querys, sino pedir los datos que vamos a utilizar realmente. Imagínate una tabla con 100 campos en donde hay varios blobs e información diversa que no puede ser distribuida en otras tablas para mantener toda la información en un solo lugar. Obviamente en ningún caso vas a utilizar los 100 campos a la vez..ahi está la clave.


Hay que acostumbrarse a que toda consulta debe llevar filtros siempre, a menos que sean tablas que nunca se espera crezcan mas allá de unos cuantos registros o siempre tengan el mismo número de ellos.