Consulta de una Consulta

[[Lepe]]

La carga del servidor... ¿a qué se refiere?

Si se le da dos consultas anidadas, el plan que pueda ejecutar tu SGBBDD puede ser más optimo que lo que planteas, además, puede que de las dos consultas solo tenga que regresar digamos... 100 registros, mientras que de la primera consulta, quizás deba regresar 1000 registros. En este caso es preferible cargar al SGBBDD en lugar de sobrecargar nuestra aplicación con memorytables, consultas de consultas, problemas de sincronización de datos con los datos existentes en el servidor, etc.

Respondiendo a las dudas, la solución creo que es un ClientDataset que de hecho permite agregar campos calculados, ordenar en el cliente y algunas cosas más.

Si además se le añade CacheUpdates, tendremos del lado del cliente la posibilidad de eliminar registros, crear algunos nuevos, etc todo en memoria. Solo se envían los resultados al hacer un ApplyUpdates.

Usa el Buscador, google y la propia ayuda de delphi.

Saludos

[[AzidRain]]

el ejemplo de los selects anidados funciona perfecto pero hay que tener en cuenta que el segundo select se ejecuta cada vez que se optiene un registro del primer select, de manera que si vamosa traer 100 registros terminamos ejecutando 101 querys (el query que inició o principal y 100 subquerys, uno por registro) En ese caso es mejor usar joins.

Lo que quiere hacer el inge prácticamente no se puede a no ser que haga chapuzas por ahi. No entiendo cual es el chiste de contar con un servidor dedicado para correr la BD si terminamos haciendo las consultas en forma local..

Firebird, MySQL, Postgress, DB2, MS-SQL, etc. son motores de BD preparados para realmente hacer trabajo pesado: miles de consultas, miles de registros, etc. por lo que no nos debe dar miedo cargarlos. Obviamente esto requiere tener todo el poder de cómputo que podamos comprar.

Si pasamos el trabajo de correr querys a cada cliente no sacamos ningún provecho de un motor, y seria mas facil usar tablas planas, hacer un query para traer los registros que queramos, guardar el query como una tabla en forma local y luego ejecutar otro query sobre esta última tabla...pero insisto, no le veo caso.