Prepare lento en Firebird.. y en MySQL??

[jachguate]

Empezado por xander

pero parece que nadie ha hecho aqui la prueba, y de verdad me sorprende que a estas alturas de la gente que tiene tanto tiempo trabajando con BD's con delphi nunca haya hecho esta prueba por lo menos por curiosidad

O quienes han hecho la prueba no han pasado por aqui, o no quieren desvelar sus resultados...

[tefots]

yo tambien hice la prueba con una conexion remota a una bd mysql y a otra firebird.
con mysql abrir las tablas/querys es bastante mas rápido que con firebird , pero cuando hay muchos datos , o se ejecuta una consulta que devuelva gran cantidad de datos , firebird tarda menos en devolver la consulta y los datos.

en ambos casos , hay que tener en cuenta el tipo de componentes que se usan , ya que algunos componentes se bajan todos los registros de golpe , y otros componentes se van bajando poco a poco los registros conforme vamos avanzando en el dataset.


para cualquier conexion remota a través de internet a cualquier base de datos (mysql , firebird ,sqlserver , etc) yo recomiendo crear una vpn , la cual cifra y comprime los paketes ip.
si haceis la prueba , con firebird y usando una vpn , la velocidad se incrementa mucho.

[xander]

Porque no mantendrá la aplicación delphi el código de ejecución de la consulta cuando se prepara en tiempo de diseño???

Eso estaria muy bien porque asi podría mantener preparadas desde el tiempo de diseño las consultas que se ejecutarán mas frecuentemente y no habría necesidad de prepararlas cada vez que se ejecute el programa; si se pudiera hacer eso estaria de pelos; pocos, pero pelos.

[jachguate]

Empezado por xander

Porque no mantendrá la aplicación delphi el código de ejecución de la consulta cuando se prepara en tiempo de diseño???

Por que dicho "código" reside en el servidor de base de datos y delphi no tiene (o no debiera tener) acceso a él.

Hasta luego.

[xander]

Empezado por jachguate

Por que dicho "código" reside en el servidor de base de datos y delphi no tiene (o no debiera tener) acceso a él.

Pues por lo menos con Firebird si es posible tener acceso al código de ejecución, en IBObjects Jason Wharton tiene un demo sobre como puedes tu simple mortal crear tu propia consulta en BLR para traer datos del servidor, no quiero decir que este muy fácil, para nada, hay que conocer mucho de la sintaxis del lenguaje para hacer algo ínfimo, pero en si es lo que hace el servidor traducir tu solicitud SQL en código BLR. Y se supone que eso es lo que hace el preparar una consulta.

Si se pudiera mantener el código BLR generado por una consulta determinada haciendo la preparación en tiempo de diseño, para despues solo hacer las solucitudes al servidor usando esa sentencia BLR se ahorraria el tiempo de preparacion en ejecución que es lo que generalmente se tarda mas.