IBX vs IBO

[Voutarks]

Me gustaría saber si alguien utiliza o ha utilizado los IbObjects para acceso directo a Interbase/Firebird y si es así cual es la ventaja sobre los componentes Interbase Express que vienen con Delphi.

[Rudi]

En mi experiencia personal los IbObjects son mas rapidos que los IBX, ademas te facilitan el tratamiento de transacciones mucho mas que IBX, tanto si lo quieres hacer a mano o con las opciones por defecto.

Por otro lado si piensas utilizar Firebir en lugar de Interbase ni pienses en utilizar IBX pues a partir de la versión 1.5 de firebird es notable la diferencia de los servidores, IbObjects ofrece soporte para ambos (Interbase/Firebird), IBX solo trabaja con Interbase (Firebird hasta la versión 1.0).

Aunque tu pregunta fue acerca de los componentes de acceso nativo, IbObjects tambien cuenta con componentes compatibles con Tdataset, lo cual resulta muy util si deseas migrar aplicaciones hechas con este tipo de componentes para que utilicen Interbase/Firebird.

[Voutarks]

Hola Rudi, ya hablé contigo una vez, creo, preguntándote sobre el mesaje que aparece al arrancar un programa cliente.

La verdad es que no he tenido mucho tiempo para utilizar mejor estos componentes pero ¿de verdad crees que son más rápidos que los IBX?. Lo que a mi me parece es que son más lentos, precio lógico que pagan por ofrecer muchas más funciones.

Lo que he hecho hasta ahora es hacer un par de pruebas de velocidad, haciendo inserción, modificación y borrado de 100.000 registros en bloque y cronometrando el tiempo. Con los IbObjects he probado con los Tdataset y con varios de los nativos (TIB_Query, TIB_DSQL, etc), además de jugar con algunos parámetros de estos componentes para ver si mejoraban el rendimiento. El resultado era siempre goleada de los IBX: 3 veces más rápido que los IbObjects nativos y 4 veces más que los compatibles Tdataset.

Hay otra prueba de velocidad que alguien realizó recientemente y cuyo resultado publicó en el newsgroup de los IbObjects. Se trataba de modificar en bloque 50.000 registros y además de recorrer todo ese conjunto de datos con IBX y un TDBGrid de toda la vida contra IbObjects nativo con su TIB_Grid. ¿Los resultados?... idénticos. Los IBX eran entre el 300 y el 400 % más rápidos. Al mensaje contestaron miembros ilustres de la comunidad IbObjects/Firebird como Helen Borrie o Lucas Franzen, diciendo primero que habría que ajustar ciertos parámetros de los IbObjects, ¡pero no dijeron cuales! y al final terminaron contestando que no se iban a molestar en esa prueba, ya que nadie en sano juicio pondría en un programa final serio un grid para recorrer 50.000 registros, así que sólo era una prueba simbólica; con lo cual llego yo a la conclusión de que efectivamente son más lentos los IbObjects que IBX.

Bien, como dije antes veo esto totalmente lógico, ya que los IBX son bastante simples y se limitan bastante a funciones básicas directamente soportadas por la API de Interbase. Según el creador de los IBObjects, Jason Wharton, esto deja las complicaciones del lado del programador, ya que los IbObjects hacen que se ahorre mucho trabajo.

Bien, aquí es donde yo pregunto ¿vale la pena aprender los IbObjects? Resulta que son un conjunto de componentes bastante amplio y con una cantidad de propiedades y métodos algo abrumadora. Aparte tampoco encuentro completa la documentación de los Ibobjects, ya que no definen bien la mayoría de estas propiedades. Por otro lado si quiero enlazar con otros componentes como los ReportBuilder o los de la casa Devexpress no puedo utilizar los IBO nativos, tengo que utilizar los compatibles Tdataset, y vuelvo a preguntarme ¿compensa lo que gano al utilizar estos componentes?

Algo concreto: dicen que los IbObjects manejan mucho mejor las transacciones ¿en que sentido? ¿que hacen exactamente? Con IBX estoy siempre controlando el comienzo y el fin de las mismas, y es un poco pesado. No me fío de dejar que el usuario tenga un grid en la pantalla horas y horas sin modificar nada, simplemente navegando por él y esté esa transanción ahí, abierta. Tampoco me gusta utilizar CommitRetaining. Así que casi siempre los grids estarán en blanco hasta que el usuario busque algo y resulta que no se por qué oscuro motivo a la mayoría de los usuarios no les gustan los grids de datos sin datos ya que prefieren su pantalla siempre inundada de filas aunque no las necesiten. ¿Como me pueden ayudar en este sentido los IbObjects?

Ya lo sé he hecho muchas preguntas, pero son las dudas que tengo actualmente.

[Rudi]

Hola Voutarks.

Puede que tengas razon con respecto a la velocidad debido a que yo comencé a utilizar los IbObjects hace un par de años y en aquel entonces realice las mismas pruebas comparatives entre IBX, FIBPlus y lo IbObjects y los resultados apuntaban mejores prestaciones en los IbObjects, pero desde entonces me despreocupé por seguir comparandolos, lo mas probable es que debido al crecimiento que han tenido los IbObjects hayan perdido, como te diste cuenta, su velocidad inicial, preocupandose mas por facilitar el trabajo del programador.

Puede que mi respuesta a tu pregunta sobre quien era mejor fue apresurada y peor aun basada en mis pruebas hechas hace un par de años.

Con respecto a tu pregunta sobre tener el grid vacío para evitar tener la transacción activa, sé que con los IbObjects puedes tener los datos montados en el grid sin mayor problema pues utiliza un cache de los datos, lo que tienes que hacer es colocar unos disparadores en el servidor para que te avisen (al cliente) cuando ocurre una manipulación de datos (DML) y proceder a actualizar (como prefieras, los registros alterados o todos los registros).

Por cierto, en la manipulación por bloques (bucles/ciclos) de datos es mucho mas rapido trabajar con los datos del cache. por ejemplo:
{**********************************}
q.BeginBusy( false );
try
q.BufferFirst;
While not q.BufferEOF do
begin
.
.
lo que tengas que hacer...
.
.
q.BufferNext;
end;
finally
q.EndBusy;
end;
{**********************************}

En lo que tenga algo de tiempo voy a tratar de actualizarme...

[Voutarks]

Oye Rudi, he hecho más pruebas y tengo que decir que con respecto a la velocidad, simplemente cambiando la propiedad autocommit del Ib_Transaction a false y manejando uno mismo las transacciones el rendimiento resultó ser casi idéntico al de IBX. Así que los resultados anteriores no tenían suficiente validez.

Bien, a igualdad de rendimiento, la superior funcionalidad de los IbObjects supongo que compensa su aprendizaje. En este punto es donde encuentro ahora una mayor dificultad. ¿Hay alguna documentación que explique claramente y con ejemplos todas las características de estos componentes?