lentitud en conexion remota con bases de datos

[anubis]

si, eso lo entiendo, solo tengo que pedir lo que realmente necesite, lo que preguntaba es cuando inicio la aplicacion tengo que asignarle la tabla al query, quiere decir que con poner solo un campo ya me sirve?.

Sobre los campos, en un query, desgraciadamente necesito todos, quiza la clave principal no.

[Casimiro Noteví]

Empezado por anubis

lo que preguntaba es cuando inicio la aplicacion tengo que asignarle la tabla al query, quiere decir que con poner solo un campo ya me sirve?.

No tienes que asignar nada a ningún query cuando inicias la aplicación. Sólamente lo que necesitas.

[Julián]

Bueno, no te llamaremos burro, pero eso que haces sí que es una burrada.
Es como si teniendo que consultar un libro, pidieras que te trajeran toda la biblioteca. Si la biblioteca está en tu casa, pues ya la tienes ahí. Pero si está en otro edificio tienes que sperar a que la carguen en camiones, y que estos lleguen a tu casa y te la descarguen.

Debes cambiar radicalmentela manera en que haces las cosas: Pide sólo un libro o unos pocos, y te los traerá Casimiro en su moto en dos segundos. Así que hazle caso y olvida el select *.

Vale, y si, como tu dices, ¿los necesitas todos?
En ese caso la soclución también es muy fácil: paginación. Usa una tabla (rejilla o grid o como se diga) con un número limitado de filas, por ejemplo 10, y la rellenas con select * from tabla limit 0,10 (segun la bd podrás usar limit u otra cosa).

Si quieres mostrar un paginador haces un select count para saber el numero total de filas y lo divides por el numero de fials en la rejilla para saber el número de páginas.

Aún así te iría como el puto culo. Por culpa de los campos blobs, que ocupan mucho. Para esto tienes dos socluciones: la mejor es no usar campos blobs y en su lugar guardar el nombre del archivo, el cual solo será enviado al navegador cuando realmente quieras verlo. La otra es no poner un * en el select y en su lugar especificar los campos que no sean blob, y traerte estsos sólo cuando quieras verlos.

Lo que no entoendo es que clase componentes usas, o de que forma lo haces, para que todo eso nque te explico no lo hagan "automáticamente".

Un salaudo!

[anubis]

gracias de nuevo por los consejos, de verdad.

Lo que voy a tener que hacer es rehacer todo el programa y aplicar lo que me habeis dicho.

Con respecto a los componentes que uso, es, por un lado, lazarus con los zeos.
Conecto la base de datos, asignaba el select * from, para las tablas (que ya no lohago ), asigno los datasources y de ahi ya las consultas iniciales.

Sobre sacar solo los registros por pagina, es buena solucion, pero como digo, voy a rehacer todo el programa. Aqui la cuestión no es que funcione sino aprender que es la base general y lo importante no desesperarme.

Gracias de nuevo a todos.

[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.